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ABSTRACT 



This thesis presents a detailed design and 
implementation of a memory manager for a kernel technology 
based secure archival storage system (SASS). The memory 
manager is part of the ccn-di s t ributed portion of the 
Security Kernel, and is solely responsible for the proper 
management of both the main memory (random access) and the 
secondary storage (direct access) of the system. The memory 
manager is designed for implementation on the ZILCG ZtCCC 
microprocessor in a multi-processor environment. The loop 
free design structure, based upon levels of abstraction, and 
a segment aliasing scheme for information confinement are 
essential elements of the overall system security provided 
by the SASS. 
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I. 



INTRODUCTION 



This thesis addresses the design and partial 
implementation of a memory manager for a member of the 
family of secuie. distributed, multi-microprocessor 
operating systems designed by Richardson and O'Connell [1] . 
The memory manager is responsible for the secure management 
of the main memory and secondary storage. The memory manager 
design was approached and conducted with distributed 
processing, multi-processing, configuration independence, 
ease of change, and internal computer security as primary 
goals. The problems faced in the design were: 

1) Developing a process which would securely manage 
file? in a multi-processor environment. 

2) Ensuring that if secondary storage was inadvertantly 
damaged, it could usually be recreated. 

3) Minimizing secondary storage accesses. 

4 ) Proper parameter passing during interprocess 
communica t i on . 

5) Developing a process with a loop-free structure 
which is configuration independent. 

6) Designing databases which optimize the memory 
management functions. 

The proper design and implementation of a memory 
management process is vital because it serves as the 
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interface between the physical storage of files in a storage 
system and the logical hierarchical file structure as viewed 
by the user (viz., the file system supervisor design by 
Parks [2] ^ . If the memory manager process does not function 
properly, the security of that system cannot be guaranteed. 

The secure family of operating systems designed by 
Richardson and O'Connell is composed of two primary modules, 
the supervisor and the security kernel. A subset of that 
system was utilized in the design of the Secure Archival 
Storage System (SASS). The design of the SASS supervisor was 
addressed by Parks [2], while the security kernel was 
addressed concurrently by Coleman f 3] . The SASS security 
kernel design is composed of f wo parts, the distributed 
kernel and the non-dis t ribu ted kernel. The design of the 
distributed kernel was conducted by Coleman [3], and 
processor management was implemented by Reitz f^] . This 
thesis presents the design and implemer ta t. i cn cf t'^e 
non-distributed kernel. In the SASS design, the 
non-distributed kernel consists solely of the memory 
manager . 

The design of the memory manager and its data bases va^ 
completed. The initial code was written in PLZ/SYS, but 
could not be compiled due to the lack of a PLZ/SYS compiler. 
A thread of the high level code was selected, hand compiled 
into PIZ/A^m, and run on the Z3220 developmental module. 
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The PLM/ASM thread listing is presented as a computer 
program appended tc this thesis. 

A. BACKGROUND 

Operating systems were initally developed during an era 
when hardware was a scarce and expensive resource, while 
software was relatively inexpensive. The initial system 
design technique was to begin with the hardware 
configuration and to build the operating system upon it. 'The 
"bottom up” design technique was practical, but it made the 
operating system extremely hardware dependent. Hardware 
configuration changes would often force a major software 
redesign, but as long as hardware costs were dominant, 
software modification was the logical alternative. As the 
functions required of the operating system increased, new 
procedures were haphazardly added to the operating system, 
often introducing new problems. Maintenance and debugging cf 
the operating system became extremely cumbersome and time 
consuming. 

The increased usage of computers in such fields as 
finance and sensitive information handling uncove red a 
serious problem with most operating systems. Information 
stored within a computer system was generally quite 
accessible to anyone who had a working knowledge of 
operating system design and structure, regardless cf ary 
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ad-hoc attempts to provide internal computer security. Data 
stored in information systems, with security added in, could 
not he certified as being totally secure [14} . 

Recent technological development? have reversed the 
economics of the computer design environment. 
Microprocessors have become abundant, powerful, and 
inexpensive. The relative cost of software, or the 
otherhand, has steadily increased until it now dominates the 
overall cost of a computer system. This reversal has two 
basic implications. First, software must be treated as the 
expensive commodity. Software developed should therefore be 
logical, easy to read, relatively maintenance free, and easy 
to debug. Second, more powerful hardware can he used to 
perform functions previously performed with software, and 
thus hardware (multiprocessors) can he utilized to achieve 
overall system speed goals. 

The SASS was developed utilizing a "top down" design 
technique, with information security as a primary design 
issue. Security was designed into the system based upon the 
security kernel concept [5]. The security kernel provides a 
secure environment by ensuring that just one element of the 
system (the security kernel) is sufficient to provide the 
internal system security. All accesses of data stored within 
the computer system must be validated by the security 
kernel . 
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BASIC CONCEPT 5/D ZFINITIGNS 



1 . Process 

Organick [6] defines a process as a set of related 
procedures and data undergoing execution and manipulation, 
respectively, "by one of possibly several processors of a 
computer. The process is a logical rather than a physical 
entity, and can be viewed as a set of related procedures and 
data (referred to as the process' address space) and a print 
of execution within that address space. Each process may 
have associated with it such logical attributps as a 
security class authorization and a unique identifier. In 
order to execute, the process must be mapped onto (bound to) 
a physical processor within the computer system. 

A process may exist in on° of three states: blocked, 
ready, or running. When in a blocked state, the process must 
wait for the occurrerce of some event before execution can 
continue (for example, an access of secondary storage's. ’-/hen 
the ev°nt for which a blocked process is waiting occurs, the 
process is placed into the ready state which indicates that 
the process can run when a processor is available to be 
assigned to it. The process is in thp running state when it 
is executing on a processor. 
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2 . Process Switching 



Vhen a process is blocked, the physical orocesscr 
upon which it is scheduled is idle. For efficiency reasons, 
it makes sense to freeze that process, save the execution 
point (program status registers, program counter, execution 
stack) and the address space, and then schedule another 
process to run on that processor. This is referred to as 
process switching (or multiprogramming), and is an important 
aspect of a distributed operating syster. The overall 
system, such as SASS, can be viewed as a set of cooperating 
processes that interact to perform the intended functions. 

Efficient process switching can only be achieved 
with the supnort of some hardware switching mechanism that 
will unload the blocked process' address space, and load the 
address space of the scheduled process. Some systems have a 
EIR (descriptor base register) which is used to point to a 
list cf multiple address spaces (one per process) which 
exists in memory. Thus to change an address space, the EIR 
need only be changed. The SAS3 utilizes a Z-SPCtf supporting 
hardware device entitled a Memory Management Unit (MMU) to 
allow efficient process switching. The MMU consists of a set 
of registers (64 or ITS in the SASS design) which contain 
the process' address space. Thus process switching would 
involve the switching of control to another hardware MMU (if 
a hardware MMU were available for each process), or 
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alternately loading a software MMU image (which is always 
kept current) into the MMU whenever a process switch is 
required. The SASS currently maintains a software imame 
for each process. 

3 . Protection Domains 

A user's process executing on a computer system has 
an address space which includes the user provided procedures 
and data, and also those portions of the distributed 
operating system which are required to support execution of 
his program. To maintain system integrity and security, it 
becomes mandatory to protect the operating system from being 
altered or manipulated by the user's procedures. To achieve 
this, the process' address space is divided into a set of 
hierarchical domains which ensure that the segments of the 
operating system are orotected from the user. Since the top 
down design cf the operating system provides a strict, 
hierarchal structure, the domains of the operating system 
are also hierarchical in structure (viz., are protection 
rings). In the design cf the secure operating system family, 
three domains were defined: the user, the supervisor, and 
the kernel. 

Operating system segments which manage the actual 
shared physical resources reside in the kernel. The kernel 
is the most privileged domain of the address space. It can 
be envisioned as a mini-operating system that does all the 
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(executable) can only be accessed within the kernel. Globe! 
(system wide) data cases are restricted to access by only 
the security kernel to prevent the possibility of an 
unauthorized inter-prc cess leakage of information [?] . 

Th° supervisor domain resides between the most 
privileged kernel domain and the least privileged user 
domain. The supervisor contains those segments of the 
operating system which are required to provide such common 
services as creatine* a hierarchical file system. The 
supervisor deals with the logical entities (segments) as 
viewed by the user, and manae-es these segments by calls to 
the kernel. To preserve the integrity of the file system, 
the user is placed in the least privileged domain, and can 
communicate directly with the supervisor only. 

Multiple nrotecticn domains may be implemented via 
either a hardware and/or a software ring structure. A 
hardware irolemer ta t i on is more efficient, however the VLSI 
microprocessors currently being manufactured provide for 
only two protection domains. The present design cf the SASS 
requires two domains, separating the supervisor and the 
security kernel. The Z8000 microprocessor provides the S^SS 
with the hardware ring structure tv providing two execution 
modes, the system mode and the normal mode. The kernel 
executes in the system mode and thus has access to all 
segments, machine instructions, and hardware facilities. The 
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supervisor executes in the norral rrode, and thus only has 
access to a subset of the instruction set and segments. The 
supervisor does not have access to those instructions which 
manipulate the system hardware, such as special I/O and 
execution mode control instructions. 

4 . Segmentation 

Segmentation is the key element of a secure system. 
A segment is a logical grouping of information such as a 
procedure, array, or data area [?j • The address spare of a 
process consists of those segments that may be addressed by 
that proc°ss. Segmentation is the management cf these 
segments within the address space. In order to address a 
specific location within a segment two dimensions are 
required, an identification of the segment (e.g.. segment 
number) and an offset from the base of the segment. 

3ach segment may have several logical attributes 
associated with it. These attributes can include segment 
size, classification, and access permitted (read, write, 
execute). The physical attributes of a segment include the 
current base address, and whether or not the segment is "in 
core". The segment's attributes and its physical location in 
memory are contained in a segment descriptor. The segment 
descriptors for a process are often contained in a 
descriptor list (viz., an PM’J image for the SPSS) to 
facilitate the memory management of its address space. 
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Segmentation permits multiple processes to share a 
single segment and to avoid the requirement of maintaining 
duplicate copies in memory. This eliminates the po c sibility 
of having conflicting data when multiple copies of the same 
segment are maintained. Segmentation also enables the 
enforcement of controlled access to a particular segment, 
since each process can have different access (read/write) to 
stored segments. This capability of enforcing controlled 
access is crucial to security. 

Segmentation provides a mechanism for the 
virtualization of memory (although not provided in the 
SASS). If a user requests access to a segment to which he 
has access rights, and that segment is not in main memory, a 
memory fault will occur which will cause that segment to he 
loaded into main memory (another segment may have to be 
moved to s c condary storage to make room). Thus tc the user, 
the size of main memory is virtualized into the size of the 
process' address space. 

5 . Information Security 

As previously stated, tnere is an ever increasing 
demand for a computer system to provide for the secure 
storage of information. This security cannot be added to an 
existing operating system with a large degree of confidence 
that the resulting security system cannot be avoided or 
bypassed. In order to be demonstrably adequate, security 
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must be designed into the operating system, and must he part 
of the cornerstone upon which the operating system is built. 

There are two basic aspects of information security, 
external security and internal security. External security 

i 

prevents an infiltrator from getting to the object in which 
the desired information is stored. This can be of such form 
as a fence, a safe, a sentry, or a guard dog. If an 
infiltrator manages to penetrate these external security 
measures, he then has access to the desired information. 
Internal controls would consist of those security measures 
internal to the computer which impede and if effective, 
prevent a compromise of information. If the internal 
controls function properly, information is provided and 
exchanged only with the users wnc are explicitly authorized 
access to that information. Many information systems are 
required to store and access information of different 
security levels (e.g., secret files interspersed with 
confidential and unclassified). The internal security of 
such a "multilevel" system, must permit users and information 
to exist simultaneously at different security levels, and 
also ensure that no unauthorized accesses (either 

intentional or unintentional) are permitted. The SASS was 
designed to provide a multilevel secure storage environment. 

The data to be stored in a secure information system 
can be locked upon as a set of logical objects such as files 
or records. Associated with each of these objects is a set 
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of subjects which have access rights to that object. These 
access rights may include read access, write access, or a 
combination thereof. The non-aiscret ionary security policy 
involves checking the object's access class (oac) with the 
subject's access class (sac) to ensure that they are 
compatible. The access permitted is defined in a lattice 

model of secure information flow [S] as follows: 

sac = oac, read and write access permitted 
sac > oac, read access permitted 
sac < oac, no access permitted 
The government security classification system 
provides an example of a non-di sere t ionary security policy. 
A user with a security clearance of confidential is 

authorized read and write access to a confidential file (sac 
= oac), and he has read access (but not write) to an 

unclassified file (sac > oac). This restriction on write 
access is to prevent the inadvertant writing of confidential 
data into an unclassified file to which the subject may have 
simul taneous access (this property is often referred to as 
the :;: -property [10]). Finally, the confidential subject dc f s 
not have access to any secret files (sac < oac). 

Th c discretionary security policy involves checkirg 
the subject against an object's access control list (ACL' . 
The subject only has access to an object if he is included 
in its ACL. This policy is analagous with the government's 
"need to know" policy, wnich precludes a subject with a 



21 



secret clearance from having access rights to all secret 
information within the system. He may access only that for 
which he has a "need to know". The discretionary security 
policy thus allows the users of the system to specify who 
has access to their files. It is noted that the 
di sere ti onary security policy is a refinement of the 
security policy, and never permits a violation of the 
non-discretiona ry security policy in effect. 

The SASS was designed with the internal 
non-discretionary security to he provided hy the security 
kernel. Discretionary security is provided by the supervisor 
file system. The security kernel is based upon a 
mathematical model which has been proven correct. This 
mathematical model implements the system's security 
policies . 

The security kernel design has three prerequisites 
in order to provide a secure environment: the kernel must 
v e isolated to ensure that it cannot be modified either 
intentionally or inadvertantly. This is to ensure that the 
behavior of the kernel cannot be modified. 2) Zach and every 
attempt to access data within the system must invoke the 
kernel. 3) The kernel's correctness must be verifiable. This 
implies that the mathematical model must be proved and 
demonstrated as secure, and that the kernel implements this 
model . 
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C. THESIS STRUCTURE 



This thesis presents the detailed design of a memory 
management orocess for the 5ASS . The top down design 
technique was utilized, with levels of abstraction used to 
reduce the design complexity. The high level language 
utilized was PIZ/3YS, which was designed to be compatible 
with the ZSZCl microprocessor. PIZ/STS is a block structured 
language similar to PASCAL. The compiler which compiles from 
PIZ/SYS to the ZS2£1 instruction code is still in the 
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code 


had 


t 0 


therefore 


be 


"hand 


compiled" ( vi z . 


, tra nsla ted 


t o th e 


T r? 
* i Cl 


/ASM 


assembly 


language ) 


in order to 


run, test. 


and debug 


the 



code. Some of the procedures in the lower levels of design 
(those which use privileged instructions to directly 
manipulate the system hardware) must be directly coded using 
the assembly cod^ FLZ/ASM. These procedures were declared 
external to the Memo ry_Manage r_FLZ /S Y3_Mo dul e and ere cooed 
in the Memory_Nanager_?LZ /ASM_Mcdule . 

Chapter II of the thesis presents an overview of the 
SA3S at its current stage of development. The design of the 
memory management process, and the concurrent implementation 
of the distributed kernel processor management by ?<=itz [4] 



refined the original design of Parks and Coleman. Future 
work in the SASS will most likely reauire some refinement of 



the present design. 
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Chapt c r III presents the detailed d°si£n cf the memory 
manager rrcduls. This chapter emphasizes why certain design 
f ea tures w° re chosen, and h ow they were implemented in this 
design. 

The final chapter presents the status of research to 
date, and attempts to identify what follow-on verb is 
required. The PLZ/SYS code module and the ?LZ/AS V code 
module are presented as appendices. 
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SFCHRH ARCHIVAL STORAGE SYSTEM IHSIGM 



This chapter presents an overvip’* of the SASS in its 
current state of development. It is a summation of the 
original design efforts, and reflects refinements of those 
original designs. This overview is necessary in order to 
fully understand the interrelationship between the memory 
manager and the overall system design. It also provides a 
current base for further SASS development. 

A. BA e I C OVFFVIFW 

The purpose of the SASS is tc provide a secure archival 
file storage medium for a variable number of host ''cmputers. 
The kev design goals of the SASS Were multi-level internal 
computer security and controlled sharing of data among 
authorized users. 

Figure 1 provides an example of hew the SASS could be 
used. In this example, there are four host computers which 
reside in four separate rooms (consider each of these 
computers to be microcomputers, although any computer could 
be utilized). Fach of the four hosts are used to create and 
manipulate files of fixed predetermined security 
classification. For example, all files created by host -2 
are classified secret. Host #2 cannot create tep secret. 
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Figure 1. SASS System 
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confidential, or unclassified files (nor can he acces c top 

secret, in ‘his example). Access to each cf these rccrs is 

physically controlled to ensure that only personnel with the 
proper security clearance are authorized access. None of the 
host systems have a permanent local file storage device, and 
all are hard-wired to an I/O port of the SA5S. 

Sach host controls the access to its I/O ports (host £4 
illustrates the multi-level host connection currently 
required by the SASS). The physical protection cf the 
hard-wire is as summed to he adequate to minirize tne 

possibility of such malicious activities as wire tapping or 
emanations monitoring. Once a user of the host system 

completes his work, he can permanently store his file on the 
"ASS , which is contained in the fifth room of figure 1 (view 
the SASS as an ZS££i microcomputer with access to secondary 
storage devices). To fain access to a file, the user or 0 
of the host system must request the SASS to provide him wit" 
that file. This implies that if a malicious user pains 
access of the confidential post system, he still carrot 
access files of a higher classification. 

The SASS must be capable of performing three basic 
functions in this environment. These functions are: 1 ^ store 
a file for a host system, 2) retrieve a file for a r.ost 
system, and 3) ensure that the the files a re made available 
only to authorized users. The required capability of file 
storage and retrieval implies that processes must exist for 



each host system to perform file management end date 

trarsf°r or. hehalf of that host. To ensure the security cf 

the stored information, the SASS must ensure that the user 

of a specific host system may only address tre files *o 
which he has access. The SASS achieves the desired 
environment through a distributed operating system design 
which consists cf two primary modules, the supervisor and 
the security kernel (the security kernel actually consists 
of distributed and ncn-di stributed portions). Tach host 
system, which is hardwired to the SASS, communicates with 
its own I/O process an-’ file manager nrocess ir. the SASS 

itself. 

The supervisor is responsible for the SASS -nest system 
interface. It constructs and manages a hierarchical file 
system for its host, based upon th c files which the host has 
submitted. and controls the actual I/O (both data and 
commands) between the SASS and the host system. The 

supervisor is built upon the security kernel and performs 
the host's requests (file storage, file retrieval, I/O) by 
calls to the security kernel. These calls must he validated 
(by a gate keeper module in the SASS design) before the 
security kernel function is invoked. 

The SASS securitv kernel consists of a distributed and 
non-distributed kernel. The distributed kernel is 

distributed tc (viz., is in the address space of 1 ! every 
process, and is re=por c ible for the multiple ting the 



several processes onto the actual hardware processors', 
enforcing the non-di screti onary security policy. and 
providing the synchronization primitives for inte r-oro~ess 
communication. The non-dist rihuted kernel consists of the 
memory manager process which is responsible for the secure 
management of both main memory and secondary storage. Each 
hardware processor must have its own memory manager (ergo, 
non-di st ri hu ted kernel) in the SASS design. 

An abstract system overview of the SA5S is presented in 
figure 2. Four levels of abstraction were utilized to 
simplify the design and unders tandabi 1 i ty of the system. 

Level ? consists of the system hardware which includes 
the Zem microprocessor, the local and global memories, and 
secondary storage. The C ASS is designed to ocerate in a 
multi-microprocessor environment, the ref c r° each C? T J is 
acsip-ned its own local memory (to which it alone hc« access' 
in which it can store process local segments. The system 
contains a global memory, which every C?*J may access. 
Segments to which a user process has write access must be 
stored in global memory if more than one proce c s has 
simultaneous access to that segment. Tr.is is to ensure that 
all processes access the current copy of that shared 
writable segment. The basic storage policy is to stcr<= every 
segment within local memory if at all possible. This is to 
keep bus contention between processors, which access global 



memory, to a minimum 
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Figure 2. SA5S Abstract System Overview 
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Level 1 consist? of the distributed and non-di stributed 
kernel. The kernel is placed in (executes in) the rrost, 
privileged domain (system mode) of the ZS2E1 to ensure that 
it is protected from any manipulation (either malicious or 
inadvertant ^ . The kernel controls all access to the system 
hardware by maintaining all privileged machire instructions 
within its domain. Only the kernel may access these 
instructions. Th° distributed kernel is responsible for 
creating a virtual processor environment and enforcing the 

v 

non-di screti onary security policy. It multiplexes processes 
onto virtual processors and then multiplexes these virtual 
processor(s) onto the actual hardware processors. The 
non-di s t ribu ted kernel consists of the memory manager and is 
responsible for the secure management of both main memory 
and secondary storage. 

Level 2 consists of the supervisor, which resides in the 



less privileged 


domain (normal 


mode) 


of 


the Z5221 


microprocessor. 


It 


has access 


t 0 


all 


the machine 


instructions with 


the 


exception of 


those 


which 


mani pul ate 


the system hardware. 


The supervisor 


must 


reque s 


t the kernel 



to move segments into and out of memory and secondary 
storage via the gate keeper (a software assisted 
ring-crcssirg mechanism). The supervisor consists of two 
surrogate processes for ecch host, the I/O (input/output) 
nrocess ana the (file management) process. Ey utilizing 
the I/O and processes the supervisor is able to provide 
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host s y s t e rt . 



and manage a virtual file hierarchy for eacr. 

Each host system has I/O and Fd processes created and 
assigned at system generation. They are r.ct dynamically 
created or deleted. The supervisor ensures that each 

segment's discretionary security is enforced. 

Level 3 consists of the host computer systems. These 
systems are hardwired to the I/O ports of the Z 5000. The 
hosts communicate with the SASS via system protocols over a 
communication link. Any computer system could serve as a 
host, with each host supporting multiple users. 

3. SUPERVISOR 

Each host system is assigned the dedicated services of a 
pair of supervisor processes at system generation. These 
orocesses ane the I/O and Fd one cesses. The IF process and 
the I/O process communicate with each other via a shared 
segment entitled the "mailbox". This communication is 
synchronized via the kernel synchronization primitives vh i ~h 
act upon eventccunts and sequencers [10] . A virtual file 
system is created and maintained for each host by its Fd ar.d 
I/O processes. 

1 . File da na^emen t Process 

The Fd process is responsible for the management of 
the host's virtual file system within the SASS. The Fid 
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process interprets all the host commands and acts upon then 
in conjunction with the I/O process. 

The user of the host system views his stored data 
(within the SASS) as a hierarchy of files. Figure 3 provides 
an example of such a hierarchical file structure. To specify 
a particular file, a oathnaTe is required. The pathnare is 
simply a concatenation of the file names (given to each file 
by the user at its creation) starting at the "root” 
directory and procedinr sequentially to the desired file. 
The user is required to submit a pathname with each command 
sent to the SASS. The five basic actions to be performed 
upon files at this level are: 1) to create a file (data or 
directory), 2) to delete a file, 3) to read a file (data or 
directory), 4) to initiate or modify file attributes (sire, 
classification, access permitted), and 5) to store ''write) a 
file . 

The process is required to convert the pathname 
provided by the user, into one or more segment numbers. This 
is necessary because the notion of a file is not known 
within the kernel. All files are composed of segments, and 
must be referenced as segments within the kernel for 
manipulation and management. The process must also 
provide appropriate command handlers to ensure that the 
user's requested action is properly carried out. 

The SASS permits a host to read or write the files 
of another host, at the same security level, if 
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Figure 3. Virtual File Hierarchy 
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discretionary access is permitted. Files of a lower 
classification may "be read only (if discretions ry access is 
permitted). This file sharing is achieved by creating a link 
>etwe< 3 n the two file hierarchies. This link is entered into 
a directory file of the host, and is constructed in the same 
manner as a pathname (viz., it is a concatenation of 
filenames). The kernel enforces a read only access to the 
lower classified files, which prevents the possibility of 
writing data (through a link) of a higher classification 
into a file of lover classification. 

The database utilized by the Fy process to manage 
the host's Mies is the Fy Known Segment Table (FM_KSTK The 
F v _K S T is a list of those segments wnich are known to (viz., 
within the address space cf) the FM process. Figure 4 
provides an example of the Fy_KST structure. 

Whenever a user of a host syster requests access to 
a specific file, the Fy_KST is searched to determine if that 
pathname (segment) is already known. If it is known, the 
request is passed to the kernel , via the ga t e_keeper , with 
the appropriate segment number, for the desired action. If 
the pathname is not known, the segment number of the desired 
file's directory (parent) file and an entry number are sent 
to the kernel with the request to make that segment known. 
If the request is authorized by the kernel, a segm c nt number 
and access mode authorized are returned. The returned 
segment number and mode are then entered into the Fh KS7 
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Figure 4. File Manager Known Segment Table. 
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with that serpent's pathname. Once the segment is known, the 
desired user action can he carried out. 

The user requests to create or delete files are 
simply passed to the appropriate kernel procedure, via the 
gate keeper, hy the FM process (after a discretionary 
security check). No entries are added or deleted from the 
FM_EST during create or delete requests (they invoke kernel 
primitives which add or delete entries from a kernel data 
base) . 

Should the FM process request that a segment he 
swapped into memory and memory is full, an error rode will 
he returned to the FM process from the kernel (it is noted 
that this is a per process memory alio cation, thus the 
memory state cannot he affected hy its use hy other 
processes). The Fid process will then select a segment to he 
removed from core to make room for the desired segment. The 
current design calls for the invocation of a least recently 
used algorithm (LRU) which makes use of the Fh_KST "used" 
field to determine the least recently used segment for swap 
out . 

Discretionary security is enforced in the 
d i scretior.ay security module of the Fh 1 process. An access 
control list (ACL^ is maintained for each file within the 
file hierarchy. The ACL is simply a li = t of authorized u c ers 
(a refinement of non-discretionary security' which is 
checked for each access to that file. The discretionary 
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security module elso performs the housekeeping functions for 
the file's ACL. These functions include the addition of a 
ACL entry, the deletion of an ACL entry, and the 
initialization of an A.CL for a new file. 

It is noted that the original design of the FM 
process contained a memory manager procedure. This was 
necessary because the original SASS design called for the 
partitioning of memory such that each supervisor maintained 
his own core. The 7^ memory manager managed this virtual 
core by calls to the kernel via the gate keeper (swap_ir, 
swap_out). The current design of the non-dis tri’cuted kernel 
includes memory allocation and thus has removed the need for 
the supervisor to manage its own virtual core. Because of 
this, a 7K memorv manager is not required. 

2 . Input/Output Process 

The I/C process is responsible for all the input and 
output between th° supervisor and the host computer system. 
The I/C process receives its commands from the 7 M process 
via the shared mailbox segment. 

Lata is transfered between the host systems and the 
SASS in fired size "packets". There are three basic tvpes of 
packets, a synchronization packet, a command packet, and a 
data packet. Protocols exist for the reliable transmission 
and receipt of the packets by both the SASS and the host 
systems. The current design calls for the use cf 
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multi-packet protocols, which allows the sender to send 
several packets before he receives a receipt. 

The original design of the I/O process contained a 
M emory Manager procedure for the same reasons as the F M 
process. This procedure is no longer required due to the 
design of the non-distribut ed kernel. 

C. DISTRICTED FERN El 

The initial design of the security kernel as presented 
by Coleman [3], has been developed by Reitz [4] and the work 
presented here. The primary refinements have beer, the 

replacement of block/wakeup [3] by event counts, the 
inclusion of an event manager which contains the 

synchronization primitives, and the transfer of M VT J 
management to the memory manager. Figure 5 provides an 

overview of the security kernel design. 

1 . C-ate Keener 

Th° gate keeper is a software ring crossing 
mechanism which is utilized to ensure that the security 

kernel is isolated and tamperproof. The major issues of the 
gatekeeper design are: 1} to provide a mode switching 
mechanism for switching from normal ^supervisor) mode to 
system (kernel) mode , 2) to mask hardware preempt 

interrupts in the kernel, and 3) to check for "virtual’’ 
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Figure 5. Security Kernel resign. 
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software preempt ir.terrupts when leaving the kernel. The 
gate keeper provides the sole entry point into the kernel 
domain, validates the request and its arguments, and 
transfers the request to the appropriate kernel procedure. 
If the rate keeper encounters an error, it returns an 
appropriate error code without irvoking the kernel. 

The rate keeper uses a parameter table to validate 
the user's request (call by value only). This table contains 
the number of parameters required by each kernel function 
( crea te_se-mer t ,delete_segment , etc.), the t y p° of each 
parameter, and the type of each return parameter. If an 
error is discovered during the validation process, it sets 
the return message to an error code. If the request is 
valid, the gate keeper calls the appropriate kernel module. 

The gate keeper is a trap handler. The supervisor 
puts an argumert list and space for a return message in a 
segment (or processor registers^ within the supervisor's 
domain. V.'hen the gate keeper is invoked, it must fir c t save 
the supervisor processor registers and then retrieve the 
argument li = t (via an argument list pointer register 11 . The 
arguments are validated and if correct, passed to the 
appropriate kernel module. 

kh.en the kernel completes action taken upon the user 
request, it returns to the gate keeper. The gate keeper then 
copies a return message into the return argument (that is 
returned to the supervisor's domain), restores the 
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supervisor's er.v i roriren t , unmasks the irterrupts, and Takes 
a trap return back to the supervisor (viz., changes the node 
back to normal ) . 



Segment Manager 



The segment manager is responsible for the 
management of the segmented virtual memory. There are sir 
functions which the segment manager is called upon to 
perform. These functions are: i) to create a segment, 2 ) to 
delete a segment, 3) to make a segment known, ^ ) to make a 
segment unknown (terminate), 5) tc swap a segment into core, 
and 6) to swap a segment out of core. 

The segment manager uses the Known Segment Table 
(KST) as its data base to manage segments. The KST is a 
process lccal kernel data base which contains entries for 
all the segments which the process has made known. Figure 6 
provides an example of the KST structure. The KST size is 
fixed at system generation. It is indexed by segment numbers 
which are assigned by the segment manager. When a segment is 
made known, a "handle" (the concatenation of the Global 



Active Segment Table (G_AST) index and the segment's unique 
identification^ is returned to the segment manager by the 
memory manager. The handle is a system vide unique 
identification that is assigned to ea~h active segment 
(viz., active in the G_AST). The KST provides the mapping 
mechanism for converting the segment number into the 
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Figure 6. Known Segment Table. 
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segment's unique handle. The use of the unique handle tv the 
memory manager is what permits the controlled sharing of 
segments hy concurrent processes. Any process which requests 
to make a specific segment active will always he returned 
that segment's unique handle. Thus any one segment may exist 
within the address space of several processes (with a 
different segment number in each process) while res i dine in 
one location in memory. 

The SIZE field of the SST represents that segment's 
size. °egments exist in multiples of 256 bytes due to Z-6P££ 
hardware constraints. An upper bound upcn the segment 
size is fixed at system generation by the design parameter 
nax_segmp r t_s i ze . This is limited to 55K bytes by hardware. 
The ACCES S_^0r 3 field states the access authorized to the 
segment (r°ad, write) by this process. The Ii\'_C0?.I field is 
set when a process successfully requests the segment to he 
swapped into cor°. Th e CLASS field is used to give the 
access class (e.g., secret, confidential) of the segment. 

The usual sequence of invoking the segment manager 
functions (by the supervisor) would be as follows: 1 ' 

C rea te_Segme nt (this will invoke the memory manager to 
assign a unique identification to the created segment', 2) 
M ake_Known , which will place the segment irtc the KST, and 
3) Swap_In, which will move the segment from secondary- 
storage to main memory. To remove a segment from main memory 



to secondary storage 



the order would be 



v ake_Hnknovn , and 3) Delete_Segment . 
3 . Event Manage r 



i) Svap_Out, 2) 



The event manager provides the kernel 
synchronization priritives that are used for the 
synchronization of concurrent processes in the supervisor of 
the present SASS design. The synchronization mechanism used 
is that of eventcounts and sequencers, first 'orcDcsed by 
Heed and Pa nodi a [1C], The use of eventcounts and sequencers 
allows the ordering cf events to be controlled directly bv 
the processes involved, rather than to depend upon mutual 
exclusion mechanisms such as semaphores. The actual 
eventcounts are maintained in the memory manager module as 
they are a system vide entity and are not process local. 

Heed and Eancdia define an eventcount as an object 
that keeps a count of the number of events in a particular 
class that have occurred sc far in the execution of the 
system. The event observed can be anythin? from the input cf 
data to the system, to writing a particular segment. The 
eventcount can be viewed as an integer value, which is 
incremented with each occurrence of the observed event. The 
primitive AT VAN C 7 ( XI is used to signal the occurrence of a 
particular event, and causes the eventcount X, associated 
with that event, to be incremented. The primitive HEAT ( ” ' 
will return the value of the eventcount X. The primitive 



j»VAIT(X,n) will suspend the calling process until the value 
of eventcount X is greater than or equal to the integer 
value n. 

A sequencer can he defined as an abstract object 
that can he utilized to totally order the events of a 
particular class. The basic purpose of the sequencer is to 
provide a means to determine an ordering of a set of 

occurences of a particular event. like the eventcount. the 
sequencer can be viewed as an integer value which is 
incremented each time the primitive TICKIt(S) is called. The 
TIC TIT primitive is based upon the ticket machines often 
used in barbershops and ice croan stores. When a customer 
enters, he takes a ticket. from which the order of v v o 

arrived first and whom will be served rex t car. be 

determined . 

The use of eventcount* and sequencers by the SASS 
supervisor can be illustrated as follows. Suppose that 

segment A is currently being updated by process one. 
Iventcount A currently has the value of 9 (the eventcount 
associated with the reading of segment A). Process two 

desires to read segment A, so he obtains a ticket by 
utilizing the TICKET primitive associated with segment A. 
The value returned by TICKET is 1£ . Process two now calls 
upon the primitive, AWAI T( A , 1Z ) , which will suspend process 
two until eventcount A is valued at If. v he n process one 
completes his update, he will execute AEVANCE(A), which will 
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increment eventcour.t A to the value of 10. This will allow 
the AW AIT (A, 10 ) to return to process two, which will then he 
allowed to read segment A. 

4 . Traffic Controller 

The traffic controller performs tne function of 
scheduling processes to rur. on virtual processors. The 
traffic controller could he designed to schedule processes 
to run directly on the hardware processors, hut in this 
design, Reed 's [11] notion of a two level traffic controller 
was utilized. Thus the processes are first multiplexed onto 
virtual processors by the traffic controller. The virtual 
processors are then multiplexed onto the actual hardware 
processors by the inner traffic controller. 

A virtual processor is an abstract data structure 
which preserves all the attributes of a process in execution 
or a processor (i.e., an execution point and ar address 
space). M ultiple virtual processors may exist for a sir.ele 
physical processor. The Active Process Table (APT) is the 
data base utilized by the t raf f i c controller to co r.t o 1 and 
manage the multiplexing of processes onto virtual 
processors. Figure ? provides ar. example of the the APT. 
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Figure 7. Active Process Table. 
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veneration, the initial entries into the APT will be active 
for the life of the system. The index into the \FT is the 
FFOCESS_ID. 

The traffic controller uses the FF I OF IT 7 field of 
the P ? T to determine which process to schedule for execution 
on each virtual processor. The STATE field contains that 
process' current, state (running, blocked, or ready). The DPR 
(descriptor base register") field of the AFT provides the 
address of the MMU image fcr that process. The N ex t _P.e ady_AF 
field is a pointer which contains the index of the next 
process which is in the ready state. 

The design simplification choice of always having a 
process running on the virtual processors, introduced the 
notion of an idle process for each virtual processor. The 
idle process is loaded onto a virtual processor and placed 
into the running state whenever the number of available 
virtual processors exceeds the number of ready or running 
processes (excluding the idle process). The idle process is 
o^ the lowest priority, and will only run if nc other 
process car. be loaded. It is incapable of blocking itself, 
and thus must always be in either the running cr r<=ady 
state. 

Vhen a virtual processor becomes available, the 
traffic controller will be inv oked to schedule the highest 
priority ready process which may run on that particular 
virtual processor. If no process is ready, the Idle process 
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is scheduled. The Idle process provides a means to guarantee 
that a ready process will always he found, and that the 
Traffic Controller cannot he exited without scheduling a 
process. 

5 . Inner Traffic Controller 

The purpose of the inner traffic controller is to 
provide the multiplexing of the virtual processors onto the 
actual system processor^ s ) . and to provide the kernel 
primitives for inter-process communication within the kernel 
(Signal and ’fait). In the SASS design, each physical 
processor has a fixed set of virtual CPU's that it 
multiplexes. The primary data base utilized by the inner 
traffic controller is the Virtual Processor Table 
Figure 3 provides an example of the VFT . 

The v^T is indexed by the V i r tual _? roces so r_I i . The 
DPR, PHI, and the STATS fields are used in the same manner 
as those fields in the APT. The Idie_Fla#r simply indicates 
that the idl® process is loaded on that virtual processor. 
The Preempt fla*? indicates that a virtual preempt interrupt 
has been directed to that virtual processor. The 
?hys_Fro'-essor is a fixed field that indicates which 
hardware processor that virtual processor is scheduled to 
run on. The Nex t_?.eady_V? is a oointer to the index of the 
next ready virtual processor in the VPT for this CP TT . 

In his original design, Coleman [3] tasked the inner 
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traffic controller with the management of t v e hardware 
v emcry Management Units (which contain the process' address 
space and its attributes) and the MMU software images. In 
the present design, this function has been assigned to the 
memory manager. When the inner traffic controller unloads a 
processor, it simply writes the "■UfU into the MMU image in 
order to save the segment usage information. To load a 
orccess, it writes the MMU image into the MMU. The remory 
manager insures that the MMU image is kept current by 
updating the images whenever a segment is swapped in or 
swapped out of memory. 

The kernel synchronization primitives of SIGNAI ar.d 
WAIT are maintained within the inner traffic controller. 
These primitives are used by virtual processors within the 
kernel domain to synchronize with other virtual Drocessors 
within the kernel domain. 

T. N 0 N-T I S ?E I PUT E E KEEN EL 

The SASS non-dis tributed kernel is composed solely cf 
the memory manager process. Each physical processor has 
associated with it, its own dedicated remory manager 
process. The purpose of the process is the proper ar.d secure 
management of the main memory (both local and global), ana 
secondary storage. The actual transfer of segments from rain 
memory to secondary storage and vice-versa, is controlled by 
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the ip priory manager process. The primary data base 
by the process is the Active Segment Table, 
provides a detailed description of the process' 
and data bases. 
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Ill . MEMORY MANAGE?. PROCESS DETAIL 51 DESIGN 
A. INTRODUCTION 

The memory manager is responsible for the management of 

both main memory (local and global) and secondary storage. 

It is a ncr-di s t ribu ted portion of the kernel wi + h one 

memory manager process existing per physical processor. The 

memory manager is tasked (via signal and wait) to oerform 

memory management functions on behalf of other processes in 

the system. The major tasks of the memory manager ar° : 1) 

the allocation and deallocation of secondarv storage, 2^ the 

allocation and deallocation of global and local memory, 2) 

segment transfer from local to global memory (and vice 

versa), and 4) segment transfer frcm secondary storage to 

main memory (and vice versa). There are ten service calls 

(via signal) which task the memory manager Process tc 

perform these functions. The ten service calls are: 

CEEATE_INT?T 
PEIETE_ENTRY 
ACTIVATE 
DEACTIVATE 
SWAP IN 
SWA? “OUT 
DEACTI VATS_ALI 
MOVE_TO GIOFAL 
V CVE_TG “LOCAL 
UPDATE 

Upon completion of the service request, the memory manager 
returns The results of the operation to the waiting process 



(via signal). It then blocks itself until it is tasked to 
perform another service. The hardware configuration managed 
by the memory manager process i c depicted in figure 9. The 
shared data bases used by all memory manager processes are 
the Global Active Segment Table (G_AST), the Alias Table, 
the Disk Bit Map, and the Global Memory Bit Map. The 
processor local data bases used by each process are the 
local Active Segment Table (I_AST), the Memory v anaeeme r. t 
T Jnit Images and the Local Memory Bit Map. 

B. DESIGN PARAMETERS AMD DECISIONS 

Several factors were identified during the design rf the 
memory manager process that refined the initial kernel 
design of Coleman [ 3 ] . The two areas that were modified, were 
the management of the M.TJ images and the management of core 
memory. Beth of these functions were managed outside of the 
memory manager in the initial design. The inclusion of these 
functions in the memory manager process significantly 
improved the logical structure of the overall system design. 
Additional design parameters were established to facilitate 
the initial implementation. These dpsign parameters reed to 
he addressed before the detailed design of the remory 
manager process is presented. 

It was decided to make the block/page size of both main 
memory and secondary storage equal in size. This was to 
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secondary storage 



simplify the rapping algorithm from secondary storage to 
rain memory (and vice versa). In the initial design the 
blork/pag® size was set to 512 bytes. 

The siz® of the page table for a segment was set at one 
page (non-paged page table). This was to simplify 
implementation, and had a direct bearing on the maximum 
segment size supported in the memory manager. Tor example, a 
page size of 256 bytes will address a maximum segrert size 
of 32,269 bytes, while a page size of 512 bytes will address 
a segment size of 131,322 bytes. 



The size 



the alias table was set to one pare 



(non-paged alias table). The number of entries that the 
alias tabl o will support is limited by the size of the page 
table (viz., a page size of 512 bytes will support up to 46 
entries in the Alias Table). 

In the original design, the main memory allocation was 
external to the memory manager. This was dve to the 



partitioned memory management scheme outlined by Parks [2] 
and Coleman[3]. In the current design, all address 

assignment and segment transfer are managed by the remory 
manager. This design choice enhanced the generality of the 
design, and nrovided support for any m°mory management 
scheme (either in the memory manager or at a higher level of 
abstraction'. However, the current design still has a 
maximum core constraint for each process. 



rvnanic memory management is rot implemented in this 
design. Each process is allocated a fixed siz<= of physical 
core. Fowever, it is not a linear allocation of physical 
memory. The design supports the maximum sharing of segments 
in local and global memory. All segments that are not 
shared, or shared and do not violate the readers /wri ters 
problem will reside in lo^al memory to eliminate the global 
bus contention. The need to compact the memory (because of 
fragmentation) should be minimal in this design due tc the 
maximum sharing of segments. If contiguous memory is not 
available, the memory manager will compact main memory. 
After compaction, the memory can be allocated. 

The d°sign decision to represent memory as one 
contiguous block (not partitioned) was made to support a 
dynamic memory management scheme. Without dynamic memory 
management, the process' total physical memory can not 
exceed the systems main memory. The supervisor knows the 
size of the segments and the size of the process' virtual 
core, therefore it can manage the swap in and swat) out to 
ensure that the process' virtual core has not been exceeded. 

In the original design, the user's process inner-traffic 
controller maintained the software images of the memory 
management unit. This design required the memory manager to 
return the appropriate memory management data ( vi z ., segment 
location) to the kernel of the user's process. In the 
current design, the software images of the MMU are 



maintained by the memory manager. A descriptor base pointer 
is provided for the inner-traffic controller to multiple:: 
the process address spaces. The image data hasp does not 
need t,o he locked (to prevent race conditions) due to the 
fact that process interrupts are masked in the kernel. Thus, 
if the memory manager (a kernel process) is running then no 
other process can access the I* MU image. 

The system initialization process has not be»n addressed 
to date. However, this design has made some assumptions 
about the initial state of the system. Since the memory 
manager handles the transfer of segments from secondary 
storage to main memory, it is likely to he one of the first 
processes created. The memory manager's core image will 
consist of its cure code and data sections. The minimal 
initialization of the memory manager's data bases are 
entries for the system root and the suoervisor's segments in 
the G_AST and I_AST(s), and the in i t i al i za t on of the MkU 
images with the kernel segments. The current design does not 
call for an entry in the G_AST or L_AST for the kernel 
segments. However, when system generation is designed this 
will have to te readdressed. 

The original [3] memory manager data bas c s have been 
refined by this thesis to facilitate the memory management 
functions. The major refinements of the global and local 
active segment tables are outlined in the following section. 
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1 . Global Active Segment Table 

The Global Active Segment Table (see figure 10'' is a 
system wide, shared data base used by memory manager 
processes to manage all active segments. A lock/unlock 
mechanism is utilized to prevent any race conditions from 
occurring. The signalling process locks the G_AST before it 
signals the memory manager. This is done to nrever.t a deadly 
embrace from occurring between memory ranaeer processes, and 
also to simplify synchronization between memory managers. 
The entire G_AST is locked in this design to simplify the 
implementation (vice locking each individual entry'). 

The G_AST size is fixed at compile time. The size of 
the G_AST is the product of the G_AST record size, the 
maximum, number of processes and the number of authorized 
known segments per process. .Although the G_AST is of fixed 
size, it is plausible to dynamically manage the entries as 
proposed bv F.ichardson and 0 'Connell [l] . The current memory 
manager design could be extended to include this dynamic 
management . 

The Unique_Id field is a unique segment 
identification number in the G_AST. This field is four bytes 
wide and will provide over four billion identification 
numbers. A design choice was made not to manage the 
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reallocation of the unique_id's. Thus when a segment is 
deleted from the syster, the unique_id is not reused. 

The C-lobal_Address field is used to indicate if a 
segment resides in global or local memory. If not null, it 
contains the rlobal memory base address of a segment. A null 
entry indicates that the segment might be in local 
memory ( s ) . 

The Pro cessor s_I_ASTi_ if field is used as a connected 
processors list. The field is an array structure, indexed by 
Pro cess o r_Id . It identifies which I_AST the segment is 
active in, and provides the index into each of these tables. 
The design choice of maintaining an entry in the I_AST for 
all locally active segments implies that if all entries in 
the ?rocessors_I_ASTS_# field are null, the segment is not 
active and can be removed from the C-_AS? (viz., no 
processors are connected). 

The Flag_Pits fi°ld consists of the written bit, and 
the writable bit. The written bit is set when a segment is 
swapped out of memory, and the dM'J image indicates that it. 
has been written into. The writable bit is set during 
segment leading to indicate that some process has write 
access to that segment. 

If an active segment is a leaf, the G_ASTS_"_?arent 
field provides a back pointer to the C-_AST index of its 
uarent. This back pointer to the parent is important during 
the creation of a segment. If a request is received to 
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create a segment which has a leaf segment as its oarer.t, 
then an alias table has to be created for that parent. Also, 
the alias table of the parent's parent needs to updated 
to reflect the existence of the newly created alias table 
(see figure 11). The indirect pointer shown is the back 
pointer to the oarent via the G_A?T. 

The No_Ac tive_In_Memory field is a count of the 
nurrber of processes that have the segment in global memory. 
It is used during swap out to determine if the segrent can 
be removed from global memory. 

The N’o_Ac t ive_Eependents field is a count of the 
number of active leaf segments that are dependent on this 
entry (viz., require that this segment remain in the G_AST^. 
Each time a process activates or deactivates a dependent 
segment this field is incremented or decremented. 

The Size field is the size of the segment in bytes. 
The ?age_Table_locaticn field is the disk location of the 
oage table for a segment, and the A1 ias_Tabl e_Lo ca t i on field 
is the disk location of the alias table for the segment. The 
Alias_Tabl'= field car. be null to indicate that no alias 
table exists for the segment. 

The last three fields are used in the management of 
eventccunts and sequencers [4]. The Sequencer ^ield is used 
to issue a service number for a segment. The Instar.ce_l 
field and Instance_2 field are eventccunts (i.e., are used 
to indicate the next number of occurences of some event). 
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2. Local Active Segment Table 



The Local Active Segment Table (see figure 12) is a 
processor local data base. The L_AST contains the 
characteristics (viz., segment number, access) of each 
locally active segment. An entry exists for each segment 
that is active in a process "loaded" on this CPU and in 
local memory. The first field of the L_AST contains th° 
memory address of the segment. If the segment is not in 
memory, this field is used to indicate whether the L_AST 
entry is available or active. The Segment_.No/Access field is 
a combination of segment number and authorized access. It is 
an array of records data structure that is inhered by DPR_~. 
The first record element (viz., most s i gni f i car. t bit'' is used 
to indicate the access (read or read/write) Permitted to 
that segment. The second record element (viz., the next 
seven bits) is used to indicate the segment number. A null 
segment number indicates that the process does not have the 
segment active. 

3 . Alias Table 

The alias table (see figure 13' is a memory manager 
data base which is associated with each ron l°af segm°rt in 
the kernel. An aliasing scheme is used to prevent passing 
systemwide information (unique_id.) out of the kernel. 
Segments can only be created through a mentor segment and 
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entry number into the mentor's alias table. When a segment 
is created, an entry rust he made in its mentor segment's 
alias table. Thus the mentor segment must he known before 
that segment can he created. 

The alias table consists of a heade r and an array 
structure of entries. The header has two "pointers" fvi?., 
disk addresses'), one that links the alias table to its 
associated segment and one that links the alias table to the 
mentor segment's alias table. The header is provided to 
support the re-construction of the file system after a 
system crash due to device I/O errors. It is not used at all 
during normal operations. Each entry in the array structure 
consists of five fields for identifying the created 
segments. The Unique_Ia field contains tne unique 
identification number for the segment. The Size field is 
used to r°cord the size of the segment. The Class field 
contains the appropriate securitv access class of the 
segment . The Page_Table_Location field has the disk address 
of the page table. A null entry indicates a zero-length 
segment. The A 1 ia s_TaM e_L o ca t io n field has the disk address 
of the alias table for the segment. A null entry indicates 
that the segment is a leaf segment. 

4 . Memory M anagement Unit Image 

The Memory Management Unit Image (MMU_Image) is a 
processor local data base. It is an array structure that is 
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irdexed "by the D3R_£. Each MM T J_Irage (see figure 14) 
includes a software representation of the segment descriptor 
registers (SDR) for the hardware bibiU [12], This is ir. 
exactly the format used hy the special I/O instructions for 
loading/unloading the h’M'J hardware. The SD^. contains the, 
Dase_Address , limit and Attribute fields for each loaded 
segment in the process' address soace. The Pase_Address 
field contains the base address of the segments in memory 
(local or global). The Limit field is the nurber of blocks 
of contiguous storage for each segment (zero indicates one 
block). The Attribute field contains eight flags. Five flags 
are used for protecting the segment against certain tvpes of 
access, two encode the type of accesses made tc the segment 
(read/write), and one indicates the special structure of the 
segment d?] . Five of the eight flags in the attribute field 
are used by the memory manager. The "system only" and 
"execute only" flags are used to protect the code of the 
kernel from malicious or unintentional modifications. Tr.e 
"read only" flag is used to control the read or write access 
tc a segment. The "change" flag is used to indicate that, the 
segment has been written into, and the ”c? T J-ir.hi bi t " flag is 
used tc indicate that the segment is not in memory. 

The last two fields of the MM'J_Image are the 
Rlock_ : Tsed field and the yaximum_Available_?lccks field. 
These two fields are used in the mangement of each process' 
virtual core and are not associated with the hardware yy 7 J . 
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5. Memory Alio cation /Deallocation Bit Maps 



All of the memory allocatior./deallocatior hit maps 
(see figure 15) are basically the same structure. Secondary 
storage, global memory and. local memory are managed tv 
memory hit maps. The Iisk_Bit_Map is a global resource that 
is protected from race conditions via the locking convention 
for the G_AST. Tach hit in the bit man is associated with a 
block of secondary storage. A zero indicates a free block of 
storage while a one indicates an allocated block of storage. 
The Glctal_f'emory_Ii t_Yap is used to manage global memory. 
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Global_ v emory_P it_Map and is used to manage local memory. 
The Iocal_Memory_Bi t_h‘ap is not locked since it is not a 
shared resource between memory managers. 

I. BASIC FUNCTIONS 

The detailed source code for the basic functions and 
main line of the memory manager are presented in appendices 
A and B. Appendix A lists the procedures which are coded in 
PIZ/SYS, while Appendix B lists the lower level hardware 
dependent procedures which ar° coded in PIZ/ASM. 

PIZ/SYS is a high level modular structured language 
which produces a machine-independent Z-ccde similar to 
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Figure 15. Memory Allocation/Deallocation Map. 
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PASCAL'S F-code . The translator from Z-~ode tc Z-S000 
machine code is currently under development at ZILOC- Inc., 
thus the PIZ/STS module could not he compiled on the ZPCC0 
[13] . PLZ/ASM is a symbolic assembly larguage that is used 
to program the Z-8000. The assembler supports Structured 
programming and produces a relocatable 7-8000 object module. 

In the discussion of the memory manager design, a 
pseudo-code similar to PLZ/SYS is utilized. The rationale 
for using this pseudo-code was to provide a summary of the 
memory manager source code, and to facilitate the 
presentation of this design. 

It is assumed that the memory manager is initialized 
into the ready state at system generation (as previously 
mentioned). When the memory manager is initially placed into 
the running state, it will bloc’s itself (via a call to the 
kernel primitive Wait). Wait will return a message from a 
signalling process. This message is interpreted by the 
memory manager to determine the requested function and its 
required arguments. The function code is used to enter a 
case statement, which directs the request to the appropriate 
memory marager procedure. 

When the requested action is completed, the memory 
manager returns a success code (and any additional required 
data) to the signalling process via a call to the kernel 
primitive Signal. This call will awaken the process which 
requested the action to be taken, and place the returned 
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message into that process' message queue, ‘/hen that action 
is completed, the memory manager will return to the top of 
the loop structure and block itself tc wait for the the next 
request. The main line pseudo-code of the memory manager 
process is displayed in figure 16. 

1 . Create an Alias Table Entry 

Create_Entry is invoked when a user desires to 
create a segment. A segment is created by allocating 
secondary storage, and by making an entry (unique_id, 
secondary storage location, size, classification) into it's 
mentor segment's alias table. This implies that the mentor 
segment must have an alias table associated with it, and 
that the mentor segment must be active in order to obtain 
the secondary storage location of the alias table. 

The mentor segment can be in one of two states. It 
may have children (viz., have an alias table', or it may be 
a leaf segment (viz., not have an alias table). If the 
mentor segment has children, it has an alias table and this 
alias table can be read into core, secondary storage can be 
allocated, and the data can be entered into the alias table. 
If the mentor segment is a leaf, an alias table must be 
created for that segment before it (the alias table) can be 
read into core and data entered into it (see figure 11'. 

The pseudo-code for CR2AT3_2NT?.Y PROCEDURE is 
presented in figure 17., The arguments passed to Create_Entry 
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EM TRY 

INITIALIZE PROCESSOR LOCAL_VAR I ARLES 
DO 

! CHECE_IF_MSG_OUEUE_SMPTY ! 

VF_ID, MSC- := WAIT 

FUNCTION, ARGUMENTS := VALIDATE MSG (MSG) 

IF FUNCTION 

CASE CP.EATS_ENTRY THEN 

SUCCESS_COFE := CREATE ENTRY (ARGUMENTS) 
CASS DELETS_ENTP.Y THEN 

SUCCESS _CODE := DELETE_SNTRY (ARGUMENTS) 
CASE ACTIVATE THEN 

S T JCCESS_CODE := ACTIVATE (ARGUMENTS) 

CASE DEACTIVATE THEN 

S T JCCESS_CODS := DEACTIVATE (ARGUMENTS) 

CASE SWA?_ IN THEN 

SUCCSSS_CODE := SWA?_IN (ARGUMENTS) 

CASE S A?_OUT THEN 

SUCCESS_CODE := SVAP_OUT (ARGUMENTS) 

CASE DEACTIVATE ALL THEN 

SUCCESS_CODE := D E A CT I V AT E_ AL L (ARGUMENTS' 
CASS MOVE T0_GL03AL THEM 

Sl T CCESS_CODE := MOVS_TO GLOBAL (ARGUMENTS) 
CASE MOVE_TO_LCCAL THEN 

SUCCESS_CODS := MOVS_TO_LOCAL (ARGUMENTS) 
CASE UPDATE THEN 

SUCCSSS_CODE := UPDATE (ARGUMENTS) 

El 

SIGNAL (VP_ID , S T JCCSSS_CODE , ARGUMENTS) 

CD 

END MEMORY MANAGER PIZ/SYS MODULE 



Figure 16. Memory manager Mainline Code. 
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CREATE_SNTRY PROCEDURE (FAR_INDSX WORD, ENTRI_# WORD, 

SIZE WORD, CLASS BYTE) 

RETURNS ( SUCCES S_COEE BYTE ) 

LOCAL PDFS WORD, FAGF_TABLE LOC WORD 
ENTRY 

IE ALIAS _TA2LS_D0SS_N0T_EXI$T THEN 
S TT CCESS_CODE := CREATS_AL I A c _TAP LE 
IF S'JCCES S_CODE <> VALID THEN RETURN 
FI 
FI 

ELKS := C ALCULATE_NC_PLKS_RFO (SIZE) 

SUCCESS_C ODE := READ_ALI AS_TABLE ( 

G_AST [?A?._I NDSX] .ALIAS_TABL E LOC) 

IF S T JCCESS_COEE <> VALID THEN RETURN 
FI 

SUCCESS _CODE := CHECK_rUF_ENTRY ! ir. alias tatle ! 

IF SUC CESS_CODE O VALID THEN FETURN 

FI 

SUCCESS _CODE , F AGF_TAELE_LOC : = A LLOC_SSC_STORAGE (BITS' 
IF $UCCESS_CGDE O VALID THEN RETURN 

FI 

H?DATE_ALIAS _TAFLE(ENT?.T_#, SIZE. CLASS, FAOE_TABLE_ICC ' 
SUCCESS_C OLE := WRITS ALIAS TABLE ( 

g_ast!far_indsx] .ALIAS TABIE_LOC) 
IF SUCCESS_CODS <> VALID THEN RETURN 
ELSE S T JCCESS_CODE := SSG_CREAT r D 
FI 

END CFEATE ENTRY 



Figure 17. Create Entry Pseudo-code. 
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are the index into the G_AST for the mentor segment, the 
entry number into its alias table, the size of the segment 
to be created, and the security access class of that 
segment. The return parameter is a success code, which would 
be ”seg_crea ted” for a successful segment creation. 

When invoked, Create_2ntry will determine which 
state the mentor segment is in (viz., if it has an alias 
table). If an alias table does not exist for the mentor 
segment, one is created and the alias table of the mentor 
segment's parent is updated. The alias table is read into 
core and a duplicate entry oaeck is made. If no duplicate 
entry exists, the segment size is converted from bytes to 
blocks, and the secondary storage is allocated for non-zero 
sized segments. The appropriate data is entered into the 
alias table and the alias table is then written back to 
secondary storage. 

2. Delete an Alias Table Entry 

Dele te_Ent ry is invoked when a user desires to 
delete a segment. A segment is deleted by deallocating 
secondary storage, and by removing the appropriate entry 
from the alias table of its mentor segment (the reverse 
logic of C reate_in t ry ) . This implies that the mentor segment 
must be active at the time of deletion. There are three 
conditions that can be encountered during the deletion of a 
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segment: the segment to he deleted may he an inactive leaf 
segment, an active leaf segment, or a mentor segmert. 

If the segment to he deleted is an inactive leaf 
segment (viz., has been swapped out of core, and does not 
have an entry in the G_A3T), the secondary storage can he 
deallocated and the entry deleted from the mentor segment's 
alias table. If the segment is an active leaf segment, the 
segment must first he swapped out of core and deactivated 
before it can be deleted. This entails signalling the memory 
manager of each processor, in which the segment is active, 
to swap out and deactivate the segment. 

If the segment to be deleted is a mentor segment, an 
alias table exists for that segment . If the alias table is 
empty, the secondary storage for the alias table and the 
segment car be deallocated, and the entry for the deleted 
segment can be removed from its mentor's alias table. If the 
alias table contains any entries, the segment cannot be 
deleted because these entries would be lost. If this 
condition is encountered a success code cf 
"leaf_segment_exis ts " is returned to the process which 
requested to delete the entry. Due to a confinement problem 
in "upgraded" segments, this 5uccess_code cannot always be 
passed outside of the kernel. This implies that the segment 
manager must strictly prohibit deletion of a segment with an 
access class not equal to that of the process. 
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The pseudo-code for rELSTE_ENTRY_??;CCEr T JF.E is 
presented in figure 16. The parameters that are passed to 
this procedure are the parent's index into the G_AST and the 
entry number into the parent's alias table of the segment to 
he deleted. The al ias_tahle_loc field is checked to 
determine the state of the mentor segment (either a leaf or 
a node), and the appropriate action is then taken. A success 
code is returned to indicate the results of this procedure. 

3 . Activate a Segment 

Activate is invoked when a user desires to make a 
segment known by adding a segment to his address space. A 
segment is activated by making an entry into the L_AST for 
that processor, and the G_AST. The activated segment could 
be in one of three states? it could have previously been 
activated by another process and have a current entry in 
both the G_AST and L_AST, it cculd have previously been 
activated by another process on a different processor and 
have an entry in the G_AST but not the I_AST, or it could be 
inactive and have an entry in neither the G_AST nor the 
L_AST . 

If the segment to be activated already has entries 
in both the L_AST and G_A3T, these entries need only be 
updated to indicate that another process has activated the 
segment. The segment number is entered into the 
Segment_Mo/Access_Auth field of the L_AST, and if the 
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DELETE_FNTKY PROCEDURE ( ?AE_I NDEX WORD, SNTRY_# WORE 
RETURNS ( SUCCES S_COI E BYTE) 

LOCAL PAP_INDEX rfORD 
ENTRY 

! Check if the passed mentor segment has an alias table 
IF G_AST [PAP_I NEEX] . ALIAS_TA£LE_LOC O NULL 
S T JCCSSS_COI'E := REaE_ALI AS _ TABLE ( 

G_AST[FAR_IND2X] .ALIAS TABLE_LOC ) 

ELSE 

SUCCESS_CODE := N0_CEILD_T0_D2LETS 
FI 

IF SUCCESS _CODE <> VALID TEEN RETURN 
FI 

! Determine if segment has children in alias table ! 

IF ALI AS_TArLE NOT_EMPTY THEN 

SUCCESS_CODE := LEAF_SEGMENT_EX ISTS 
RETURN ! Delption will delete children ! 

ELSE 

! Search G_AST with UNICUE_ID to verify segment inactive 
IF ACT I VE_ IN_C_AST THEN 

1 Check if active in AST ! 

IF ACT IVE_IN_L_AST THEN 

DEACTIVATE_ALL (G_AST_INDEX, L_A3T INDEX) 
FI 

! Check G_AST to verify segment inactive in other L_AST' 
IF ACT IVE_I N_OTEEE_L_AST THEN 

SIGNAL_T0_DEACTIVATE_ALL ( GAS T_I NDFX ) 

FI 

FI 

FP FE_SEC_S T0RAC-E_0F_S EG_<R_AL I AS IF_EXI STS 
DSLSTE_ALIAS_TABLE_ENTPY 
FI 

DELETE AI IAS _T ABLE ENTRY 
SUCCESS_CODE := WrTtS_ALIAS_TA£I E ( 

G_AS T [ F AR_I N DS X j . A L I A S _ TA £ I E_L OC ) 

IF SUCCESS _CODE = VALID TFSN 

S r JCCESS_CODE := SEG_DEL2TEL 
FI 

END DELETE ENTRY 



Figure 16. Delete Entry Pseudo-code. 
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segment is a leaf, its mentor's N'c_Active_Dependents field 
in the G_AST is incremented. In this design, the G_AST is 
always searched to determine if the segment has been 
previously activated by another process. 

If the segment to be activated has an entry in the 
G_AST but not the I_AST, an entry must be made in the L_AST 
and the G_AST must be updated. The L_AST is searched to 
determine an available index. The segment number is entered 
into the I_AST, and the index number is entered into the 
G_AST Processors_L_AST3_# field. If the segment. to be 
activated is a leaf segment, its mentor's 
No_Active_Dependents field in the G_AST is incremented. 

If the activated segment does not have an entry in 
either the G_AST or L_AST, an entry must be made in both. 
The G_AST is searched to find an available index, and the 
entry is made. The I_AST is then searched to find an 
available index, and the entry is made. The L_AST index is 
then entered into the G_AST Frocessors_L_A3T3_£ field. If 
the activated segment is a leaf, the No_Active_rependent s 
field of its mentor's G_AST entry is incremented. 

The pseudo-code for ACTIVATE FKGC33UFE is presented 
in figure 19. The parameters that, are passed are the DFF._# 
of the signalling process, the mentor segment's index into 
the G_AST, the alias table entry number, and the segment, 
number of the activated segment. The mentor segment is 
always checked to determine if it has an associated alias 
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ACTIVATE PROCEDURE (DBR_# BYTE, PAR_INDEX WORT, 

ENTRY _# WORD, SSGKENT_NO BYTE) 
RETURNS (SUCCESS_CC-DE BYTE, RET_C-_AS T_EANDLE HANDLE, 

CUSS BYTE, SIZE W CRD) 

LOCAL C-_INDEX WORD , L INDEX WORD 
ENTRY 

! Verify that oassed segment is a mentor segment ! 

IT G_AST [PAR_INDEX] .All AS_TAELE_LOC <> 0 THEN 
SUCCESS_CODE := READ ALIAS TAELE ( 

G AST [PAR_INDEXJ . ALIAS _TARLE_LOC 

ELSE 

SUCCESS CODE := ALIAS_DGSS NOT EXIST 
FI 

IF SUCCESS_CODS O VALID THEN RETURN 
FI 

! Check G_AST to determine if active ! 

SUCCESS_CODS, INDEX := SEARCH G_AST (UNIQ T JZ_ID) 

IF S TT CCESS_CODE = FOUND TFEN 
IF SEGMENT IN_L AST THEN 
UPDATE L_A ST (SEC-YSNT_NO) 

ELSE 

MAKS_L AST_ENTRY ( D3R # , S EG M ENT_NO ) 

UFDATS_G AST (L_INDSX) 

IF G_AST [INDEX] . AL I AS _T ABLF_L0 C = NULL THEN 
g_ast [PAR_INDEX] ,NO_DEPENDENTS_ACTIVE - = 1 
FI 
FI 

ELSE 

MAXE_G_AS T_ENTRY (ENTRY_# ) 

M AKE_L_AST_ ENTRY (PAR_INDEX , ENTRY_# ^ 

FI 

SUCCES S _CODE := SEG_ACTI VATSD 
END ACTIVATE 



Figure 19. Activate Pseudo-code. 
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table. If it does not, the success code of 
"alias_does_not_exist" is returned. If the alias table does 
exist, it is read into core and the entry number is used as 
an index to obtain the activated segment's unique_id. The 
G_AST is then searched to determine if the segment has 
already been activated. If the unique_id is found, the G_AST 
is updated and the L_AST is either updated or an entry is 
made (depending on whether an entry existed or not). If the 
unique_id of the segment was not found during the search of 
the G_A.ST , an entry must be made in both the G_AST and 
L_AST. Activate returns the activated segment's 
classification, size, and handle to the signalling process. 

4. Deactivate a Segment 

Deactivate is invoked when a user desires to remove 
a segment from his address space. To deactivate a segment., 
the memory manager either removes or updates an entry in 
both the L_AST and G_AST. Deactivate uses the reverse logic 
of activate. Once a segment is deactivated, it can only be 
reactivated via its mentor's alias table as discussed in 
activate. If a process requests to deactivate a segment 
which has not been swapped out of the process' virtual core, 
the memory manager swaps the segment out and updates the MM T J 
image before the segment is deactivated. The segment to be 
deactivated could be in one of thr®e states? more than one 
process could concurrently hold the segment active in the 
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L_AST, the segment could he held active "by one process in 
the I_AST and more than one in the C-_AST, the segment could 
he held active hy onlv one process in both the L_AST and the 
G_AST . 

Deactivation of leaf segments and mentor segments 
are handled differently. If the segment is a mentor segment 
and has active dependents, it cannot he removed from the 
G_AST (even though no prooess currently nas that segment 
active). This is based on the design decision which requires 
that the mentor of all active leaf segments remain in the 
G_AST to allow access to its alias table. The mentor's alias 
table must he accessible when an alias table is created for 
a dependent leaf segment. If a leaf segment is deactivated, 
the N o_Ac t i ve_Dependen t s field of its mentor's G_AST entry 
is decremented. A mentor segment can only be removed from 
the G_AST if no process holds it active, and it has no 
active dependents. 

If more than one process concurrently hold a segment 
active in the I_AST, and one of them signals to deactivate 
that segment, the entry in the L_AST is updated. This is 
accomplished by nulling out the Segment_No/Access_. fi uth field 
of the L_AST for the appropriate process. If required, the 
No_Act ive_Dependen ts field of its mentor segment's G_AST 
entry is decremented. 
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If only one process holds the segment active in the 
L_AST, and that Process signals to deactivate the segment, 
the L_AST entry for that segment is removed. The 
Fro cess ors_I_ASTE_£ is updated and checked to determine if 
there are other connected processors. If there are no ether 
connected processors and the segment has no active 
dependents, the segment is removed from the G_AST. If there 
are other connected processors, the G_A3T is updated. If the 
deactivated segment is a leaf, the mentor segment's 
No_Acti ve_Dependents field in the G_AST is decremented . 

The pseudo-code fer DEACTIVATE PROCEDURE is 
presented in figure 2C. The parameters that are passed to 
the memory manager are the DBH_£ of the signalling process, 
and the index into the G_AST for the segment to be 
deactivated. The procedure first updates the L_\ST, and then 
removes the entry if no local process holds the segment 
active. The G_AST is then updated, and its mentor segment is 
checked (if the deactivated segment was a leaf;, to 
determine if it can be removed. If no processes currently 
hold the segment active, and it has no active dppendents, 
the segment is removed from the C-_A5T. 

5 . Swan a Segment In 

SWA?_IN is invoked when a user desires to swan a 
segment into main memory (global or local) from secondary 
storage. A segment is swapped into main memory by obtaining 
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DEACTIVATE PROCEDURE ( DBR_£ BITE, PAR_I NDEX WORD) 
RETURNS (SUCCESS_CODE BITE) 

LOCAL INDEX WORD 
ENTRY 

! Check if segment is in core ! 

IF G_AST [INDEX] .NO_AC'TI V3_IN_ V EM0RY O 0 THEN 

!~Check ima?e to determine if in local memory 

IF IN_L0CAL_MF M 0RY THEN 

SUCCESS_CODE := OUT ( DBR_# , INDEX) 

FI 

FI 

! Remove process segment_no entry in L_AST ! 

L_AST [L_ INDEX] .SEGMENT_NO/ACCESS_AUTK [DBR_#3 = £ 
CHECK_IF_ACTI VE_IN_L AST ( L_AST_INDEX ) 

IF N07_ACT IVE_IN L AST THEN 

L AST [L_INDEXj .MEM0RY_ADDR := AVAILABLE 
FI 

! Check if deleted segment was a leaf ! 

IE G_AST [INDEX] . G_ASTE_#_PAR <> 0 THEN 

G_AST [PAR_ INDEX] . NO_DEPENDENTS_ACTIVE -= 1 
! Determine if parent car. he removed ! 
CHECK_F0R_R3M07AL (PAR INDEX) 

FI 



! Determine if deactivated segment can he removed ! 
CKECK_F0R_REr07AL (INDEX) 

S rT C CES S _C0DE := SEG_DEACT'I VATED 
END DEACTIVATE 



Figure 20. 



Deactivate Pseudo-code. 



the secondary storage location of its page table from the 
G_AST, allocating the required amount of main memory, and 
reading the segment into the allocated main memory. The 
segment must be active before it can be swapped into core, 
and the required main memory space must be available. Three 
conditions can be encountered during the invocation of 

SVAP_IN. The segment can already be located in global 

/ 

memory, the segment can already be located in ore or more 
local memories, or the segment may only reside in secondary 
s to rage . 

If the segment is not in local or global memory, 
local memory is allocated, the segment is read into the 
allocated memory, and the appropriate entries are made in 
the MKT image, the L_AST ana the G_AST. If the segment is 
already in global memory, it can be assumed that the segment 
is shared and writable. In this case the only required 
actions are to update the G_AST and 1_/ST. The 
No_Acti ve_In_Memo ry field of the G_AST entry is incremented, 
and the MM T J image is updated to reflect the swapped in 
segment's core address and attributes. 

If the segment already resides in one or more local 
memories, it must be determined if the segment is "shared" 
and "writable". A segment is "shared" if it exists in more 
than one local memory, a segment is "writable" if one 
process has write access to that segment. If the segment is 
not shared or not writable and in local memory, the 
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appropriate entries are updated in the MM’J image, the L_AST, 
and the C-_AST. If the segment does not reside in local 
memory, the required amount of local memory is allocated, 
the segment is read into the allocated memory, and the 
appropriate entries are made in the MMU image, the L_AST, 
and the G_AST. 

If the segment is shared, writable, and in local 
memory, the segment must he moved to global memory. If the 
segment is not in the memory manager's local memory, it 
signals another memory manager to move the segment to mlobal 
memory. After the segment is moved to global memory, the 
memory manager signals all of the connected memory manager's 
to update their L_AST and MtiU data bases. When all local 
data bases are current, the memory manager updates the G_AST 
and returns a success code of seg_activated. 

The pseudo-code for SWA?_IN PROCEDURE is presented 
in figure 21. The arguments passed to SWAP_IN are the 
G_AST_INDEX of the segment to be moved in, the process' 
T3R_#, and the access authorized. SWAP_IN vill convert the 
segment size from bytes to blocks, and verify that the 
process' core will not be exceeded. If the virtual core will 
be exceeded, a success code of "co re_space_exceeded" will be 
returned. If write access is permitted, the writable bit is 
set. Checks are then performed to determine the segment's 
storage location (local or global), and the appropriate 
action is taken. 
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SWAP IN PROCEDURE ( INDEX WORD, DER_£ 

\CCESS_AUTH SITS ) 

RETURNS (SUCCESS_CODE BYTE) 

LOCAL L_INDEX WORD, ELKS WORD 
ENTRY 

BLES := CALC'JLATE_NO ._OF_BLKS (G_AST [INDEX] . SIZE) 
SUCC3SS_C0DE := CHECK_MAX_LI NEAR_C ORE (ELKS) 

IF SUCCFSS_CODS = V IRTUAL_L I NEAF_CORE_FULL THEN 
RETURN 
FI 

C-_AST [INDEX] .NC_SEGMENTS_IN_MEMORY *= 1 

IF ACC ESS_A T JTH = WRITE THEN 

G AST [INDEX] .FLAG_3ITS : = W RITABLE_BIT_SET 
FI 

! Determine if segment can be put in local memory ! 

IF G_A?T [INDEX] .FLAG_3ITS AND WR ITA3LE_ V ASK = e 
OFIF G_AST [INDEX] . NO_ACl I VE_I N_ME v OET <T= 1 THFN 
! Determine if already in local memory ! 

CHEC K_LOCAL_M EMORY (L_AST_INDEX ) 

IF NOT_IN LOCAL_MFMORY THEN 

ALL0CAT3_L0CAL MEMORY ( 3LKS ) 

READ_S EGMEN T T?AGE_TA3LE_L0C , BASE ADDR) 

I._AST [L_ INDEX] := BAS E_ADDP. 

FI 

EL ^ E 

IF not_in_gloeal_memo?j teen 

UPDATE MMU 

UFDATE_L_AST 

RETURN 

ELSE 

ALLOC AT E_ GLOB AL_MEMOP.Y ( ELKS ) 

IF IN LOCAL_MEMX?.Y THEN 

v OVE_TO_GLOSAL (L_INDEX, 3 ASE_ADDR , SIZE) 

ELSE 

S IC-NAL_OTEER_M EMORY MANAGERS ( INDEX ,BASE_ADDR ' 
FI 
FI 
FI 

U?DATE_ V MU_IMAGE (r3R_#,S3G_# ,BASE_AEDR , ACCESS ,BLKS ) 
UPDATE_L_AST_ACCESS ( L_ INDEX , ACCESS , DBR_ 4 ) 

SUCCESS_COrF := SWAPPED_IN 
END SWA? IN 



Figure 21. Swap_In Pseudo-code. 
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6. Swap a Segment Out 



SWA?_0UT is invoked when a user desires to move a 
segment out of core. A segment is swapped out of core by 
obtaining its secondary storage location, writing the 
segment tc that location (if required), and deallocating tne 
main memory used. The decision to write the segment is 
determined by the G_AST written bit. This bit is set 
whenever the segment has been modified . The segment to be 
swapped out car be in one of two states: the segment can be 
in local memory, or the segment can be in global memory. 

If one orocess has the segment in local memory and 
the written bit is set, the segment is written into 
secondary storage and the local memory is deallocated. If 
the written bit is not set, the local memory need only be 
deallocated. If more than one process has the segment in the 
same local memory, the segment remains in cere. The 
appropriate image is updated to reflect the segments 

deletion. and the G_AST No_Act ive_Ir,_Memc ry field is 
d ec rement ed . 

All segments in global memory are shared and 
writable. If a process requests the segment to be swapped 
out, the segment remains in memory. The MWJ image is updated 
to reflect the segment's deletion, and the G_. a S? 
No_Ac tive_In_f^emory field is decremented. If the 
No_Active_In_^emory indicates that one process has the 



segment in core, its memory manager is signalled to move the 
segment to local memory. 

The pseudo-code for S'fAF_OUT PKOCZEUP.E is presented 
ir. figure 22. The arguments passed to SWAP_O r JT are the E3P_# 
of the signalling process, and the C-_AST_I NIEX of the 
segment to he removed. The return parameter is a success 
code. SWA?_0UT removes the segment from the process's 
virtual core, deletes the segment from its MtfU image, and 
decrements the N'o_Active_In_hemory field. If the segment can 
he removed from memory, it is det°rmined wnich memory can he 
deallocated. If the segment has been modified, it is written 
hack to secondary storage and the appropriate memory 
deallocated. If the segment has not been modified, the 
appropriate memory is deallocated. If after the deletion one 
process has the segment in global memory, its memory manager 
need only he signalled to move the segment to local memory, 
'tfhen SWA?_OUT successfully completes, it returns a success 
code of "swapped out". 

7. Deactivate All Segments 



D E AC T I V AT E_A I L is invoked when it becomes necessary 
to remove a segment from every process' address space. Each 
process is checked to determine if the segment is active. If 
a process has the segment active, it is deactivated from its 
address space. The pseudo code for Peac ti vate_al 1 is 
ill is t rated in figure 23. The parameters passed to 
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SWAP_OUT PROCEDURE (PER_* PITS, INDEX WORD) 

RETURNS (SUCCESS CODE BYTE) 

ENTRY 

ELKS := G_AST [INDEX] .SIZE / 31K_SIZE 
FREE_PROCSSS LINEAR_CORS (ELKS) 

DELFTE_WU_ENTEY (DER #, SEG_#^ 

G_AST [INDEX] . NO_S SGMENT S_I N_yEMOR Y -= 1 

l Determine if segment has beer written into ! 

IF M y U_I t M AC-E [DFR_#] . SDF. [SFG_#] . A T T R I B U T E S = W H I T T F N THEN 
! If s°gment has "been written into, update G_AST ! 
C-_AST [INDEX] .EIAC-_EITS := WRITTEN 
FI 

! Determine if segment is in global memory ! 

IE G_AST [INDEX] .GIOBAL_ADDR O NULL THEN 

IF G_AST [INDEX] . N0_SEGMF NTS _ IN EMORY = 0 
ANDIF G_AST[INDEX] ,FLAG_BITS = WRITTEN THEN 
WEITE_SEG (PAGS_1AELE_L0C , MEM0RY_A DDR ) 
FF.EZ_LOCAI_BIT_!*AP ( l*E; v GRY_ADIR , ELKS > 

EISE 

IF G_AST [INDEX] . N0_ACT I VE_ I N_MEM0RY ^ to THEN 
FREE_ICCAL_EIT_MAP ( KEMCRY_ArDR , ELKS ) 

FI 

FI 

ELSE ! If not in global memory ! 

IF G_AST [INDEX] .NO_ACTIVE_IN_HEMCF Y = 2 
ANDIF OJVST [INDEX] .FLAG_EITS = WRITTEN THEN 
WPITF SEG ( PAGE_TAELS_LOC , GLOBAL A.DBP ) 
FRES_GIOEAL_E IT_MAP (GLOBAL ADDR.'bLKS) 

ELSE 

IF C-_AST [INDEX] ,NO_ACTI?E_IN_ v 1EMORY = 2 THEN 
FREE GIOBAI_EIT_N , AP (GL^BAL_ADDF , ELKS) 

FI 

FI 

FI 

SUCCES S_C ODE := SVAPPEr_OUT 
END SWAP OUT 



Figure 22. Swap_Out Pseudo-oode. 
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DEACTIVATE_ALL PROCEDURE (INDEX iORD, L_ I NDEX VORD) 
RETURNS (SUCCESS_COrE LYTE) 

ENTR T 

LOCAL I BYTE 
I := e 
DO 

IE I = MAX_DBR_# THEN 
EXIT 
El 

IE I_AST [L_I\'DEX] .SSCNSNT_N D/ACCSSS_AUTK [I ] 
<> ZERO THEN 

SUCCESS_CODS := DEACTIVATE (I, INDEX) 

IE SUCCESS_CODE O S EG_DEACTI VATSD THEN 
RETURN 
El 
El 

I += 1 
OD 

SUCCESS _C0DE := VALID 
END DEACTIVATE ALL 



Figure 23. Deactivate All Pseudo-code. 
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Deactivate_all are the deactivated segment's G_AST index and 
the L_AST index. The I_AST is searched by to determine 
which process has the segment active. If the check reveals 
that the segment is active, it is deactivated by calling 
Deactivate. If the segment was successfully deactivated from 
all processes, a success_coae of valid is returned. 

S . Move a Segment to Global Memory 

M 0VF_T0_0L0TAL is invoked when it becomes necessary 
to move a segment from local to global memory. If a segment 
resides in one or more local memories, and a process with 
write access swaps that segment into core, or if a segment 
resides in in local memory (with write access) and another 
process with read access requests the segment swapped in, 
the segment is moved from a local to global memory to avoid 
a secondary storage access. If the segment resides in the 
running memory manager's local memory, it will affect the 
segment transfer, otherwise it will signal another memory 
manager of a connected processor to affect the transfer. 
Figure 24 illistrates the pseudo-code for MOVE_TO_G I03AI . 
Once the segment has been moved to global memory, the 
signalled memory manager will update the MM'J images for all 
connected processes, and deallocate the freed local memory. 
A success code of completed will be returned to the 
signalling memory manager. The parameters passed to the 
memory manager are the segment's L_AST index , the global 
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MOV E_TO_GL OPAL PROCEDURE (L_INDEX v/ORD, GLOBAL ADPF. 'V GRD , 

size vop.m 

RETURNS (SUCCESS CODE PYTE) 

ENTRY 

! Move segment from local memory to global memory ! 
DO_MEMO T> Y_MOVE ( MSMORY_ADDR f GL03AI_ADDR ) 

I_AST [INDEX] .MEMORY_ADDR := AVAILABLE 
! Update the MMU image to reflect new address ! 

DO eor_ai,i_dbr's 

IE L_AST [L_INDEX] . SEGMENT_NO/ACCESS_AUTH <> e ANDIE 
M V U_I M AGE [DEB_#] .SDF[SEG_*] . ATTRIPUTES = IN_LOCAL THEN 
MMU_IMAGE [DBR_#] .sdr[sbg_#] .BASE_ADD? :=GLOPAI_AIDR 
El 
OD 

SUCCESS_CODE := VALID 
END MOVE TO GLOBAL 



Figure 24. Move To Global Pseudo-code. 



memory address of the rove, and the size of the segment. 
This information is passed because the G_A. C T is locked 
during this request. 

9 . Move a Segment to Local Memory 

MO?F_TO_IOCAI is invoked when it becomes necessary 
to move a segment from global to local memory. This occurs 
when on p o^ two processes which hold a segment, in global 
memory swaps the segment out. The segment is moved from 
global memory to the local memory of the remaining process. 
Figure 25 illustrates the pseudo-code for MOVE_TO_LCCAL . The 
narameters passed to the memory manager are the segment's 
L_AST ind°x, the global address of the segment, and the size 
of the segment. The return parameter is e success code. The 
MMU irages of the signalled process are updated after the 
move has been made, and the global memory is deallocated. 

1? . Update the MMU Image 

UPDATE is invoked following a ^0VF_?0_C-ICEAL 
operation. After a segment has been moved from local memory 
to global memory, it is necessary to signal the memory 
managers of all connected processors to update t.heir MMU 
images and L_AST with the current location of the segment. 
They must also deallocate the moved segment's local memory. 
Figure 26 illustrates the pseudo-code of UPDATE. The 
parameters passed to the memory manager are the segment's 
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MOVE_TO_LOCAL PROCEDURE (L_Ii\iDEX WORD, C-LOEAL_ADD* WORD, 

SIZE WORD 1 

RETURNS (SUCCESS_CODE BYTE ) 

ENTRY 

ELKS := SIZE / ELK_SIZF 

3ASE_ADD?.FSS := AILOCATE_LOC AL_UEMORY (SDKS) 

! Move fror global to local perccrv ! 

MEMORY_MOVE ( GLO£AL_AEEE , BASE_AEDRES S , SIZE) 

I_AST [L_INEEX] .MEmORT_ADDR := 3ASE ADDRESS 
DO FOR_ALL D3R 'S 

IF I AS T T I INDEX] .SEGMENT_NO/ACCESS_AUTE <> ? ANDIF 
MMU_IMAGETD3R_#] .SDR[SEG_#] .ATTRI3UTSS=IN_I0CAL then 
MMU_ IMAGE [DBR_#] .SDR[SEG_#] . BAS E_ADER : = £ASE_ADDRES S 
FI 
OD 

SUCCESS_CODE := VALID 
END MOVE TO LOCAL 



Figure 25. Move To Local pseudo-code. 
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TTPE'ATE PPOCEDUEF (l_INDEX WORD, GLOFAl_APEE WORD, 

SIZE WORD) 

RETURNS (SUCCESS_CCDE BYTE) 

ENTRY 

DO FOR All DBR'S 

IF I“ASTTL_INDEX] .SEGMENT NO/ACCESS_AUTH <> G ANDIF 
MMU_lMAGF [DPR #] .SPR[SEC-_#r. ATTR IBUTES = IN_I OC AI THEN 
M^J_IMAGE[D3R_#] .SDR[SEC- #J .3ASE_ADDR : = 

GLOBAL ADD? 

FI 

OD 

ELKS := SIZE / BLK_SIZE 
FREE_IOCAL_BIT MAP (MEMORY ADD?. , 3IKS ) 

I_AST[L_IMDEX] 7mEMORY_ADDP. := ACTIVE 
SUCCESS CODE := VALID 
END UPDATE 



Figure 26 . Update Pseudo-code. 
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L_AST index, the new global address for the segment, and the 
size of the segment. The return parameter is a success code. 

3. SUGARY 

In this chapter the detailed design of the memory 
manager process has been presented. The purpose of the 
memory manager was outlined, followed hy a detailed 
discussion of the memory manager's data bases. The design 
presented has identified ten basic functions for the memory 
manager. The implementation details of these functions are 
presented in Appendix A. The success codes returned by the 
memory manager are presented in figure 27. 

This design has assumed that the kernel level 
inter-process synchronization primitives will be Salt.zer's 
signal and wait primi t ives [15] . This fact dominated the 
design decision to loch the G_AST in the user's process 
before it signals the memory manager. In a multi-processor 
environment, the possibility of a deadly embrace exists if 
the memory manager processes loch the G _ A S T . Should follow 
on work implement eventcounts and sequencers as kernel level 
synchronization primitives, the locking of the G_AST and 
memory manager synchronization will need to be rpaddressed. 
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SYSTEM WIDE 

INVALID 
SWAPPED IN 
SWAPPED OUT 
SEG_ACTIVATED 
S EG DEACTIVATED 
SEG_CPE ATED 
SEG_DSLETED 
VIRTUAL_COPE_FULL 
DUPI ICATE_ENTR V 
READ ERROR 
WPI TE_ERROP 
DRIVE NOT READY 



MEMORY MANAGER LOCAL 

VALID 
INVALID 
FOUND 
NOT_FOUND 
IN_LOCAL_MEMORY 
NOT IN_LOCAL_MEMORY 
! + DISK ERRORS ! 



KERNEL LOCAL 

L3AF_SEGMENT EXISTS 
NO_LEAF_EXISTS 
ALIAS_DOES_NOT_EX 1ST 
NO_CE I LD_TO_DELETE 
G_AST_FULL 
L_AST_FULL 
LOCAL_MEMORY_FULL 
GLOBAL MEMOR Y_FUI.L 
SECONDARY STORAGE FULI 



Figure 27 . Success Codes 
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IV. STATUS OF RESEARCH 



A. CONCLUSIONS 

The memory menage: design utilized state of the art 
software techniques and hardware devices. The design was 
developed tased upon ZILCG'S ZcCCl sixteen hit segmented 
mi croprocess or used in conjunction with the Z6£lfc Memory 
Management Unit [12]. A microprocessor which supports 

segmentation is required to provide access control of the 
stored data. The actual implementation of the selected 
thread was conducted upon the Z82Z2 n on-segmented 

mi croprccess or without the Z8O10 dMU . 

While information security requires that the 

microprocessor support segmentation, the memory manager was 
developed to he conf is'uration independent. The design will 
support a multi-processor environment, and can he easily 
implemented upon any microprocessor or secondary storage 
device. The loop free modular design facilitates any 
required expansion or modif ica ti on. 

Global bus contention is minimized by the memory 
manager. Segments are stored in global memory only if they 
are shared and writable. Secondary storage is accessed only 
if the segment does not currently reside in global memory or 
some local memory. The controlled sharing of segments 
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optimizes main memory usage. 

The storage of the alias tables ir. secondary storage 
supports the recreation of user file hierarchies following a 
system crash. The aliasing scheme used to address segments 
supports system security by not allowing the segment's 
memory location or unique identification to leave the memory 
manager. 

The design of the distributed kernel was clarified by 
assigning the [^MU image management to the memory manager. 
The transfer of responsibility for memory allocation and 
deallocation from the supervisor to the memory manager 
provides support for dynamic memory management. 

In conclusion, the memory manager process will securely 
manage segments in a multi-processor environment. The 
process is efficient, and is configuration independent. The 
primitives provided by the memory manager will support the 
construction of any desired supervisor/user process built 
upon the kernel . 

B. FOLLOW ON WORK 



There are several possible areas in the SASS design that 
can be looked into for continued research. The complete 
implementation of the memory manager design (refine and 
optimize the current PLZ/STS code) is one possibility. Other 
possibilities include the implementation of dynamic memory 
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management , and modifying the interface of the memory 
manager with the distributed kernel using eventcounts and 
sequencers for inter-process communication. 

The implementation of the supervisor has not been 
addressed to date. Areas of research include the 
implmenta t ion of the file manager and input/output 
processes, and the complete design and implementation of the 
user-host protocols. The implementation of the gatekeeper, 
and system initialization are other possible research areas. 
Dynamic process creation and deletion, and the introduction 
of multi-level hosts could also prove interesting. 
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APPENDIX A 



PIZ/STS SOURCE LISTINGS 



MEMORY MANAGE? PLZ SYS y OTULE 



j 



« * * * VERS 



1.0 



I 



CONSTANT 



FALSE 

TRUE 

AVAILAPLE 

ACTIVE 

ZERO 

NULL 

NULL PAGE 



0 

1 

0 ! AST 

1 ! AST 



0 

°zeeee 

0 



ENTRY AVAIL 
ENTFY AC TIE 



i 



SUCCESS COLES 
INVALID 



VALID 

FOUND 



a 

1 

2 



NOT_FOUND 
S’fAPPEL_IN 
SNAP? ED_CUT 
SEG_ACTIVATED 

seg_deactivated 

SEC- CRSATSL 

SEG~DELETEr 

LEAF_SEGMENT_EXISTS 

NO_LFAF_EXI STS 

G_AST_FULL 

L_AST_FULL 

IN_LOC AL_MEMORY 

NOT_IN_LOCAL_^EMOF.Y 

LOCAL_MEMOFT_FULL 

GLO'EAL_MSMORY_FULL 

V IF TU AL_ COF. E_FULL 

DUPIIC ATE_ENTR T 

NO_CFILD_TC DELETE 



3 

4 
r 

<J 

6 

7 

£ 

9 

10 

11 

12 

13 

14 

15 
15 
17 
1 £ 
13 
20 



! ATTPIPUTE MASKS 
RSAD_MASE 
WnI?E_MASX 
CHANGED_MASX 
I N _MEM ORY _M A S T. 
CLEAPEE 



Vs ( 2)11111110 
% ( 2 )00000001 
%( 2 ) 012000 20 

%( 2>00 000100 
o t a rr 



AUTHOR I ZED_ACCESS 
REA D 
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WRIT" := 1 

EXECUTE := 2 



C- AS? FLAG BITS MASKS 
" WRITABLE MASK 
WRITTEN MASK 



% (2)00000010 
%(2)0ee00ie? 



DESIGN PARAMETERS 
BLX_S I ZE 
MA7_PAGE_S I ZS 
MAX_MSG SIZE 
G MEM SIZE 

i_mem_size 
NO_OF_?ROCES SORS 

! MAX NUMBER OF 
MAX tPE NO 



:= 256 

:= ELK SIZE / 2 
:= 16 

:= ? ! SIZEOF C-LOEAL MEM 
:= ? ISIZEOI IOCAI MEMCE 
1 

DER n ' S ! 



! MAX ENTRIES IN G_AST 
G_AST_I IMIT := 100 

! MAX FNTRIES IN L_AST 
I_AST_LIMIT := 100 

! SIZE OF ALIAS TABLE 
M A7_ V N TRY NO := 32 

! fc OF SEGMENTS PER PROCESS 



NO_SEG_EESC REG : = 54 

FIRST_FOSS_FP EF_EL OCK := 1 

p OCESSOR LOCAI DATA ! 

PROCESSOR ID := 0 



ADDRESS WORD 



ALIAS_KSADSR FECORD [ SSG _?AGE_TA3LE_L0C WORD 

?AR_ALIAS_TAELS_LOC WORD j 



ALIAS FECOFD [ UNIOUE_ID LONG SOFT 

SIZE WORD 

CLASS WORD 

P AGF_T Ar L F_L C C WCFD 

ALIAS TABLE LOC WORE j 



SEG DSSC REG RECORD 



j^Aoij ADjl/R 
LIMIT 

ATTRIBUTES 



ADDRESS 
BYTE 
BYTE ] 



MMU RECORD [ SDR ARRAY [NO_S EG DESC_? 7 C- 

SEG_IESC_FEC J 
3IKS_*JSED WOPL 
MAX _B IX 5 WORD := ???? ] 

G_AST_REC FECOFD [ T JNIOUE_IDl LONG WCFD 

GLOEAI_ ADDR ADDRESS 

PROCESSORS L ASTE NO ARRAY 



I AST REC 



HAND!’ 



RECORD [ 

RECORD [ 
E 



[NO OR PROCESSORS 


WCFD 


FI AG FITS 


-rr r*', y~ 

31 U 


G ASTE NO FAR 


WORD 


NO ACTIVE IN MEYOFY 


WORD 


NO ACTIVE DEPENDENTS 


WORD 


SIZE1 


WORD 


PAG" TAFIE I0C1 


WORD 


All AS TAFIE 1001 


WORD 


segdencer 


WORD 


INSTANCS1 


WORD 


INSTANCE2 


WORD 



YlEY!ORY_ADDE ADDRESS 

SEC- Y E N T_N’0_ ACCESS _ A U TH 

ARRAY [YAX_D5E_.NO 5 V TZ] ] 

UMCU r _ID2 LONG WORD 
INDEX *ORE ] 



* TARTAR IE DECLARATIONS 

J# 



J* ju J# o# J# vU 



J> *>*f 



% # 1 ^ # 1 % # 1 % # 



^SECTION G DATA 



C-IOEAI 



G_A ST ARRAY [C- AST_IIYIT G_AS?_REC] 

C-IOEAI YiE v _FIT YA? ARRAY [C- YEYOR.Y_S IZZ/lc WORD] 



tSE^TIOM I DATA 



V MU_IYAGZ 
I_ AST 

All AS TA3IE 



ARRAY [MAX_DRR_NO YMTT] 

ARRAY [I _AST_I I Y I T I_AST_?.EC] 
^ECO^D [ HEADER AIIAS_HEADER 
All AS ENTRY ARRAY 



IOCAI_"EY_FIT_YA? 
DIS Y_FIT_ M A?_FUFF 
PACE TAFIE F t TEEER 



[yax_eniry_no All AS] ] 

ARRA V [I_YEY_SIZE/16 NO -I] 
ARRAY [???? ~ FITE] 

ARRAY [IIX_S 17? IYTE] 



1 1 ? 6 



SXTSRNAI 



#1% 



«*• *i# %*# v^# «*» '# s*# %•# 

-*|% #|% rf» #|% #»,% 



❖ 



%V ^-» *•# *•-» 
*1% #1% #1% #(% 



* The following procedures are coced in PLZ/ASM and are * 

* contained in a separate FLZ/ASM rodule. * 

«o } k { 



**<• %*# «*# %•# %'# 
#1% #1% #,% ^ #4% 



#l« #|« 



#i% 5j* #|% # ( * J|% 5 ( C #|« #|« #|C *|* 3 t % #j% *|* #|% i 



5| ; J 



REAI_?AC-S PROCEDURE ( E’l SK_I OC WORD . 
RETURNS ( SUCCESS_CODE BYTE ) 

READ_SEG V SNT PROCEDURE (PAGE_TA3IE_L0C 

RETURN'S ( S T JCCESS_CODE BYTE ) 

WRITS_?AGE PROCEDURE (DISK_IOC WORD , 
RETURNS ( SUCCESS CODS BYTE ) 



MEMORY.AIDR ADDRESS 

WORD , MEiMO?Y_ADDR 
ADDRESS > 

PRO v i AD DR ADDRESS > 



V 



ifRITE_SEGMENT PROCEDURE ( PAGE_TABLE_IOC WORD 
RETURNS ( SUCCESS CODE BYTE ) 



FROM _ ACER 
ADDRFSS ) 



READ DISK_BIT_MA? PROCEDURE 

SETUP NS ( SUCCESS_CODE BYTE ) 

WRIT2_DISK_3IT V A? PROCEDURE 

RETURNS T SUCCESS _CODE BYTE ) 

!? SA?CE_DIS K_B IT_ M AP PROCEDURE ( STAFT_S?.C?_LOC WOFD) 

RETURN'S ( SUC GESS_CODE BYTE, PIE_IOC WORD ) 

CIEAR_DISE_FIT_MA? PROCEDURE ( PLK_LOC WOP D 1 

FR2F_GI03AI_2IT_MAP PROCEDURE (ADD? ADDRESS, BIDS WORD ) 

EFES_ICCAt_BlT_MAP PFOCEDURE (ADD? ADDRESS, PIES WORD > 

A.ILOC_I OC AI_ v SMO?T PROCEDURE (BIKS WORD) 

RETURNS < SUCCESS_COIS BITE , BASE_ADDR ADDRESS } 

A 1 1 0 C _ G 1 0 B A I _ v E IN 0 R Y PROCEDURE (BIKS WORD) 

RETURNS ( SUCCESS_CODE BITS, BAS E_ADDR ADDRESS ) 

GET_ T JNI 0_I I PROCEDURE 

RETURNS ( ID LONG WORD. S T JCCESS_CODE BYT 1 ’ ) 

MEMORY_MOVE PROCEDURE (TO ADDRESS, PROM ADDRESS, SIZE WORD) 

7ALIDATE_MSG PROCEDUPE (MSG ARRAY [MAX_MSG_S I ZE BYTE] ) 
RETURNS ( FUNCTION BYTE, ARGUMENTS ARRAY [6 WORD] ) 



1C7 



VALIDATE JfAIT_i M SG PROCEDURE ' YSG 
RETURNS ( SUCCESS BYTE ) 



ARRAY [ v IAX_i v .SC_S I ZZ BYTE] 



INTERNAL 



U ^ * 

,% * r ^ - 



« «•» «<« »t* »•» J# <JU «)« v*» *•» »•* »•» »•» V< »'» »*» »*» »!■» *'» *'< »•» *.l» - 1 -* *•» »•< »’» <J» * 

•* ^ <*,> <-,> *,* -v* "i- ^ 'f 'i' 'i' *r* 'i' ■»,’* •»,* »t* 'i' 'i' Ri* 'i' 'i' 'i- 'i" -r 'i' 'r* - 



► Vj %V j . j# 



The READ_AL IAS _TArLE Procedure is called from the 
Create_entry procedure and Pelete_entry procedure 
The procedure will read the requested alias tat le 
from secondary storage to main memory. 



^ ^ JU «l# Jy J# % f # J# J# %*# J# 

^| % 'p #p rp #p fp #p #|% #p fp #p #p ^ #|% #p ^p #p ^p #p #p #p 



RZAD_ALIAS_TAEIE PROCEIURE ( All AS _E ISK_LOC WORE, 

yEN’OR Y_ALTR ATE P.ESS ' 

RETURNS ( SUC CESS_C0DE BYTE ) 

ENTRY 

SUCCZSS_CCrE : = ?.EAE_?AGE( ALIAS EISK_L0C, MEMO?.! A DIR- 
END READ ALIAS TAELI 



The ¥RITE_ALIAS_TArI S Procedure is called from the * 

Create_entry and Delete_entry procedures. T v e pro- * 

* cedure will write the appropriate alias tatle from 

* main memory to secondary storage. * 

JU ' 

'C* 

^ ^ %•# %V %•# *J+ J# % f *- ^ *' - ♦>* ' ^4 «*•' ^1# *** t 

# | s # i ' # p #p#p #p «p #p #p #p ^p v #p #p *p #p #p #p #p #p #p #|% #p #p #p «p #p #p * p #p fp ^p » ^p #p * , ^ f 



W ? I TE J L I A S _T A E IE PROCEDURE 

RETURNS ( SUC CSSS _C0DE 
ENTRY 

St T CCESS_COE-R := EF I TE_PAC- 
END W-ITE ALIAS TABIE 



AL I AS _D IS K_1 0 C UORE , 

! w 'Ef / CE Y_ AEEZ ALE? ESS 

YTE ) 

(ALIAS EISE LOC, YEdORY AETR ) 



ICS 






% 



The SEFRCE_AL IA5_T. S LIE Froceiure is called f ror the * 
Create_alia?_table procedure. The procedure will step * 
through the alias table until it natcr.es the passed 
unique_id with a table entry, or the table has been 
exhausted. The procedure returns a success code of 
either found or nct_found, and the appropriate index 
into the alias table. * 



%*# *** 

#|* 






- v 3j* v I 



S F A R CE _ A L I A S _T A 3 1 E PROCEDURE ( UNI0U3_ID LONG WORD ) 
RETURNS t SUCCESS _C0LE BYTE, INDEX B V TE ) 

ENTRY 

INEEX := e 

S T JCC3SS_C0D3 := NOT FOUND 
DO 

IF INDEX > MA.X_EN?RY_NO THEN EXIT 
El 

IE AIIAS_TA.£IE. ALIAS_ENTRY [INDEX] . UN I CUE_II = 

UNIQUE_ID THEN 

SUCCESS_CODS := FOUND 
EXIT 
FI 

INDEX += 1 
OD 

END SEARCH AIIAS TAPIF 



J 






•*# %•# v# 

#1% +1* #,% #1% *1* *1* *1% #1* /,% #1% 



The T JPDATS_MMU_IMAGS Procedure is called from the In * 
procedure. The procedure will update the MMU inage of * 
the appropriate process with the nencry location, * 
linit, and access authorization for the passed segnent * 
number. * 



i 



UPDATE_MMU_I mage procedure (ddr_no itte, segment_no iyte, 

A DDR ADDRESS, ACCESS r YTE , I IN' IT 3 T TE ) 
LOCAL £ TTR BYTE 
ENTRY 

MMU_IMAGE[DBR_N0] . S DR [S EGM ENT_N 0] .LAS E_ADD£ A DDR 

MM : J_IM^GEfD£R_N0] .SDR [SEGMENT NO], LIMIT : = LIMIT 
ATTR := MM* t _IMAGE[DER_NO] . S DR"[s EGMENT_M0] .ATTRIIUTES 
! CLEAR PREVIOUS ACCESS ! 

IE ACCESS = READ OKIE ACCESS = WRITE THEN 
ATT? := ATTR AND %( 2 ) 111111 1C 
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ELSE ! EXECUTE ONLY ACCESS 

ATTR := ATTR AND %( 2)11110111 
FI 

MAGE [D2R_N0] .SDH [S EC- v ENT_NO] 
END UPDATE I*!AGZ 



i 

i 



ATTRIBUTES : = 

ATT?. 0* ACCESS 



«u j# %*# «u j# 

*1* #4^ <*f*k 



*f« J# «l# %' 



% #|« «|« *,% 



* The DEIETE_^MU_ENTRT Procedure is called from the Cut * 

* procedure. The procedure will null out the W N!U image * 

* of the appropriate process for the passed segment * 

* number. * 

* Jj; 



^ § # •*# %•* tt 1 # •*# %•#%*# ^*# %♦# %•# « ( # O# %*# %'# *'# «'# %•# %•# %'• %•# %•# %'/ «*# %•# •*# %»# %' * 

<*** *§• ^4' /,» # #|« #|i #|« #|% #|« *j% #|% #|« »|^ »|«k #|« r f % #|« #,% »|% *| •> 



! 



DELFTE ^vtt_FNTFY PROCEDURE ( DB-R NO RYTE. SEGMENT_NO BYTE ' 
ENT r? T 

!^MU_IMACE fDBR_NC] . S DR [S EC-YiFNT_NO] .BA SE_ADDR := NULL 
VMIT_INAGE [DBR_N0] .SDR [SEGMFNT_NOl .LIMIT : = ZERO 
M^U_IVAGE [D3R_.N0] .SDR [S FOMENT _N0] .ATTRIBUTES := CLEARED 
END DELETE YMU ENTRY 



» »(' j(* *l» jf? J|C 5ji j|* 



o. .3* %*. 

»|» .|. »|» »|**,» »n . »(. *|» »f* 



jV *•» 



*C v 't' 'l' 'l» 'I' ' 



The FI ND_SFCONIARY_STORAGE Procedure is called from 
the Allnc_sec_storage procedure. The procedure will 
s p arch the secondary storage bit mao to find a con- 
tiguous storage location in secondary storage for the 
required number of blocks passed. The procedure will 
return a success code of either valid or invalid. 



%f * %l# J * J/ 
v *1* *r 



J# %*/ J# 



O# vl/ 



J- %*# »(# 

#4% #1% *4* 



» 



FI ND_S EC _ST GRACE PROCEDURE ( BLXS WORD ) 
RETURNS (? IT CCES5_CCDE BYTE, TABLE ARRAY 
LOCAL INDEX WORD 
I WORD 



ENTRY 

SUCCESS_CODE := READ_DISK_BIT_f / AP 
IF SUCCSSS_CODE O VALID THEN 
RETURN 



FI 



[BLK_S IZF WORD] ' 



INDEX := F IRS T_?0S S FREE_5LE 
I := 0 
DO 

SUCCESS CODE , INDEX := SEARCH DISK BIT V A? (INDEX) 



lie 



IF SUCCESS CODE <> VALID THEN 
DO 

CLZAR_BISK_BIT_NAP ( TABLE [I] ) 

IF i = Q THEN' EXIT 
FI 

I -= 1 

OD 

SUCCES S _CODZ := SZC _S TOR_FULL 
RETURN' 

FI 

TABLE fl] := INDEX 
I ~= 1 

IF I = BLKS THEN EXIT 
FI 

or 

SUCCSSS_C ODE := VALID 
END FIND SEC STOPAC-E 



«>■ •*# %•# %•# 

*4* 



% » # ( v # 



The AI LOC_ONE_PAGE Procedure is called f>on the Create 
alias_tahle procedure. The prcc°dure will fird ere 
pare of secondary storage for the creation of an alias 
table. This procedure will return a success code of 
either valid or invalid. 



*i* 

*v 









a 









%l# V# «JL» %•# O# 

# ( % # y % *|» 



' k*# <**# «iV 

#,% #1% #1% 



I 



ALLCC_ONE_FAGF PROCEDURE 

RETURNS ( StJCCESS_CODE BYTE, PAGE_LOC ATION WORD ) 
LOCAL TABLE ARRAY [BLK_S IZE WORD] 

ENTRY 

S T JCCE£S_CCDS, m ABLE := FI ND_SEC_STORAGE ( 1 ) 

IE SUCC 1? SS_CODE <> VALID THEN 
RETURN 
FI 

FAC-E_LCCAT ION : = TABLE [E] 

END ALLOC ONE PAGE 
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I * tjt * if * * if if if if if 5 ;.' * if if * if * if if V if v if if * * =:= * =:= if * 

* * 

* The ALIOC_SSC_STORAGE Procedure is called from the 

* C r e a te_e nt ry procedure. The procedure will create a 

* pare table from the allocated secondary storage, and 

* write this pare to secondary storage. This procedure 

* will return a success code of valid or invalid. 

* 

if if * if if if if if if if if if if if if if if if if if it if if if if if if if if if if if -'I'- if if * if if * if it if if if if if if if * if if :I: * 5|: f 



ALLOC_SEC_STCRAGS PROCEDURE ( ELKS WORE ) 

RETURNS ( ?AGE_TAEI E IOC WORD, SUCCZS S.CODE EYTE 
LOC^L TAELS ARRAY TSLK_SIZE WORD] 

ENTRY 

S T TCCESS_C0IS. TAEIS := FIND_SSC .STORAGE ( ELKS * 1 ) 
IS Sl T CCSSS_COBS <> VAIID THEN 
RETURN 



FI 

?AGS_TABIE_LOC := TABLE [C] 

I := 1 
DO 

FAG?_TAEIE_EUEFER [i-i] := TABLE [I] 

IF I = ELKS TFEN EXIT 
FI 



END 



I += i 

or 

DO 

IF I = MAX_? AGE.SIZS THEN 
EXIT 
FI 

PAGF_TA3LE_BUFFSR [I-l] := NULL_?AGE 

I += 1 



OD 

SUCCESS COLE 



VP.ITS_FA.GS ( PAGE TABLE_LOC, 

A PAGE TABLE 



ALLOC SEC STORAGE 



BUFFER 



) 






f £ # £ # % ^ * # # * * * # * % sj: s*s £ sjc # s*: ^ * s|s s»s :Js * # # sjc # :J: # # # * # ;Js :Jt * # s*c : 4 ’c * # 



* 

* 

* 

* 

* 

* 

* 

* 

❖ 



The CREATE_ALIAS_TAELE Procedure is called by th° 
Create_entry procedure. The procedure will allocate 
secondary storage for the creation of an alias table 
and update the mentor segment's alias table to reflect 
the created alias table's secondary storage location. 
The procedure returns a success cede c? either valid 
or invalid. 



if 

if 

it 

if 

if 

if 

❖ 

Si? 



* ❖ # * * * * * :J: * jjt* * # £ :|c ?!: * jJ: * :|i * # # * 5j: :\i * * # jjc 5 ^ s|; :Jc # % 5|c sjs * # ;Js # * # # # sj: * # * * 5 *: s|« f 
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CREATE ALIAS TABLE PROCEDURE ( ?AR_ INDEX VORD ) 
RETURNS X SUCCES S_CODE IYTE ) 

I GCAL PARENT B^TE 

A L I A S _T A BL E_L OC WORD 
ENTFY NC BYTE 



END 



ENTR V 

SUCCESS _CODF , ALIAS _TABLE_LOC := A LLOC_ ON E_ ? AGE 
PARENT t= G_AST [FAR_INDE7] .G_ASTE_NO_?A? 
SUCCESS_CODE := READ_ALIAS_TABLE (G_AST [PARENT] . 

ALIAS_TABLE LOCI , #ALIAS_TABLE ) 

IE "IJCCESS _CODE O VALIT TFEN 
RETURN 
El 

SUC CESS _CODE t ENTRY NO := SEARCE_ALIAS_TA3LE ( 

G_AST [PAR_ INDEX] .UNI0UE_ID1 ) 
IE SUCCESS_CODE = NOT_EOUND TFEN 
RETURN 



FI 

ALIAS_TABLS.ALIAS_ENTRY [ENTRY NO] . ALIAS_TABLE IOC := 

AL I A S_ T API E_ I C C 

C-_AST [?AR_INBSX] . AL I AS_TA3LE_L0C 1 : = AL I A c _TABLE_IOC 
SUCCESS_CODE := WRITE_ALIAS_TABLE ( AL IAS_TAILE_L0C . 

BALIAS TABLE 'i 



CREATE ALIAS TABLE 



1 J# ^ X X X X X X X J« 

* 1 * r % \ 






The C F E C E_Ni AX _ 7 1 RTU A L _ C ORE Procedure is called * 
by the In procedure. The procedure will verify that 
th® addition of the segment requested to be swapped in * 
will not cause the process' allccated virtual cere to * 
he exceeded. If the virtual core is not exceeded, a * 
success code of valid is returned, otherwise a success * 
code of no_memcry is returned. * 



X X«*# X • 

* 4 * * 4 * 'l' # f* 



r 



CHICK MAX_7IRTUAL_C0RE PROCEDURE ( DBR_NO BITE , 

B IF_N0_REC WORD ) 
RETURNS ( SUCCES 5 _C0DZ BYTE ) 

ENTFY 

^ vr J_I M AG3 [PER_NO] .BLFS_USED *= BLK_NC_?E0 
I? MMU_IY1A C-E [DRR_N0] . LIES _USSD > 

FMU_IMAGE [EBR_N0] . FA7_ELKS TFEN 
N U/ U_I V AGE [B?R_N0] . PDFS JJSED -= EIZ_N0_REC 
SUCCESS_CCDE := VI R?UAL_C ORE_FULL 
ELSE 
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S T 'CCESS_CCUE := VALID 
FI 

END CHEC Y MAX VICTUAL COP H 



l 



t #|% < 



The FFEE_?RCCESS_VIRTUAL_CORE Procedure is called from * 
the Out procedure. The procedure will subtract the 
size of the segment which has beer, swapped cut from 
the virtual linear core allocated to that orocess. * 






»'» «*< o# <*# 



»'* *■» *•# *'j *'< 






J 



F?SE_P?OCESS_VIRTUAL_CORE PROCEDURE ( PIK_NC V'CPI 1 
ENTRY 

W_IMA(J? l DBR_NO ].BLX5_USED -=■ 5LrT_N0 
END FF^E ?? OCESS VIRTUAL CORF 






The FREE_SEC0NLARY_ST0HAC-E Procedure is called from 
the D°lete_seg procedure. The procedure will read the 
page table of the segment to he deleted and the 
secondary storage tit map into main memory. The tit 
mao will he cleared to reflect the deallccatior of 
secondary storage, and the page table location will be 
cleared. The procedure returns a sue; 
valid or inval id . 



:ess code o 



*** ^ %*/ Jw J# ^ « 

^1* # l' *1* *1* #j% #1% #1* «l« #1% #1% #1% #1% # 



FEE 



_SEC_S TCRAOE PROCEDURE ( ?AGE_TABLF_LQC YORD ) 
RETURNS ( SUCCES S_C0LE I TIE 1 

LOCAL I WORD 

TABLEl ARRAY [ BIX_SIZE WORE ] 

ENTRY 

SUCCESS_CODE := R2aD_PAGE ( FAGE_TABI E_L0C , -TABLEl ) 
IF SUCCESS_COI'E O VALID TEEN 
RETURN 
FI 

SUCCESS_COUE := READ_DI SK_3IT_iYAP 
IF STT C CFS S _CC DF O VALID TEEN 
RETURN 
FI 

I := 2 
DO 

IF TABLEl [ I] = NULL ORIF I >= BIX SIZE THEN 
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END 



7 rr t ryi 

FI 

CI2AR_DISi:_3IT_VAP ( T A3 1 FI f I] ) 

I += 1 

or 

C I E AR _D IS K_3 1 T_i v A ? ( FAGE_TA3IE_L0C ) 
SUCCESS _COBE := VALID 
FEES c EC STORAGE 



f * 



#,* 



^ %*# %•# %*# ^ 



'# %*# «*# %•# J# %***■# 4*# 4*#* 1 



The DE1ETE_SEC- Procedure is called fr^m the lelete 
entry procedure. The procedure will •‘'ree secondary 
storage for the deleted segment, and null out the 
entry in its mentor segment's alias table. The pro- 
cedure returns a success code of either valid or in- 



DEIETE_SEG PROCEDURE ( E\'TPY_NO * GEL ) 

RETURNS ( SUC CESS_COEE 3YTS ) 

ENTRY 

SUCCESS_CODE := FREE SEC_STORAGE( 

ALIAS_TA3LE. ALIAS_ENTRT [EKTRY_NO] .?AGE_TA3LE_I0C 
IF SUC CESS _COEF O VALID THEN 
RETURN 
FI 

IF ALIAS_TAILE.ALIAS_ENTRT[ENTRY_NO] . ALIAS _TA3IE_ICC 

<> NULL THEN 

CLEAR_UIS K_BIT_UAP ( 

AI I AS _T A3 LE . AL I A S _EN?R I [E NTR Y_NC] . All AS_TArIE_ICC 
El 

ALIAS JTABLE .ALIAS_EN? T5 Y [SNTRY_NO] .UNIC T JE_IL := NULL 
END EELETE 51 EG 



t * 



4*# 4<# 4># %•# J# J# 4*# 4*# 4ltf 4># 4*# 4*# 4^ 4*# 4*« 

#|4 #|4 #|^ #|4 #,4 #|4 #|4 #|% ^4 *|4 #|4 # ( « 






4*J 4*i 



The CHEC?r_IF_ALIA.S_EMPTY Procedure is called by the 
Delete_entry procedure. The procedure will s°arch the 
alias table to determine if the table is empty. If the 
alias table is empty, the variable Al ias_ table_empt.y 
is set equal to true and returned. If the table is not 
empty, Alia s_table_empty is set equal to false. 



’*■** 4*# ^ 4*# 4 I# 4*# 4*# 4t* 4l# J# 4 I# J# 4 1 # 

V V -44 «|4 ^j4 # ( % r|4 



# | % *|4 #j4 #|« #|4 #|4 #|« #,4 #|4 # # 4 #|4 * , V t 
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CH2CK_IF_AI I AS_E V ?TY PROCEDURE 

RETURNS ( ALIAS_TABL2_EMFTY BYTE ) 
LOCAL I BYTE 



I := e 

EG 

IF I = AL I AS_TABLE_L IY IT THEN 
AI IAS_TABLF_FMPTX := TRUE 
EXIT 

^IS ^ 

IF ALIAS TABLE. ALI AS_ENTRT [I] . UN I CUE 
ALIAS_TABLEJSM?TY := FALSE 
EXIT 

ELS E 

I += 1 
FI 



OB 



FI 



END CFECE IF ALIAS EMPTY 



IB Of THEN 



• %L» +>*+ U# 4# *1# 4# 4/ 4# %U 4/ 4/ 4^ 4# 4» 4# 4/ 4# 4# 4# 4# %•# %*# 4# •*/ 4^ 4/ 

f V # l % #|« #,% #|* #,% +*% #|% * 4 * 



4^ «4# 4^ «4„ 



5*C 5*C 5*C j*' 4j 



The CHECF_LOCAL_Y~YORY Procedure is called from the In * 
procedure. The procedure determines if the segment is * 
in the processor's local memory "by examining the Y N 'U * 
image for each connected process. If the segment is in * 
the local memory, the variable Test is set equal to * 
true, otherwise it is set equal to false. * 



4# 4< 4# 4# 4# 4# W 



4# 4# 4# 4# 4/ 4# 4# 

rjO / 4 % «r J% / •> 



4* Or* 4» 4> %•# 4/ 9 

*4* V 'I' 'l % f 



CX LOCAL 


v FY0R Y 


PROCEDURE ( INDEX WORD 


RF TURN'S 


~ ( T^S T 


LYTE ) 


LOCAL 


I 


BYTE 




SEG_NO 


BYTE 


I := 0 






DO 






IF 


I - ^AX 


DBR NO THEN 




TEST := 


NCT_IN_LOCAL_mF v ORY 




RETURN 




FI 







SEC-_NC := ( L_AST[INLEX] .SEGMENT NO_ACCSSS_AUTH [I] 
AND /c (2)01111111 T 
IP SEG_N0 <> 2 THEN 

IE ( M YU_IYAGE [I j . SDR [SEG_N0] .ATTRIBUTES AND 
IN_MEMOP.Y_MASH ) <"> 0 THEN 

TEST := IN_LGCAL_MEMORY 
RETURN 
FI 
FI 
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or 



i += 1 



END CHECK LOCAL MEMORY 



f 



4*j% +y% 
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* The CHECK_FOR_RZMOVAL Procedure is called tv the Deact- 

* ivate procedure. The procedure will determine if the 

-'- segment is active in an:/ I_AST and if it has any active 

* dependents. If the segment is rot active ar.d do e s not 

* have any active dependents, the G_AST entry is removed. 

4# *J+ Jj 4# 4# 4U 4# 4# 4# *.t»*J* ^1^ 4j 4# j 1 * 4« %i# 4j 4^ 4j 4# 4# v# 4# 4# 4# 4# 4# 4# 4j 4^ 4# 4# Vj 4j 4# 4# 4# 4* 4j 4# 4# 4# % * % , 4 4# 4# % # 4# 4# 4# 4^ 4* 



PITS 

r YT V 



ECK FOR RE 


PC VAX 


LOG 


AI. 


I 






TEST 


ENT 


FT 




TSS 


m • _ 

i • ~ 


FALSE 


I : 


= e 




DO 







or 



IF I = N0_GE_?F0CESS0RS GRIP TEST - TRUE THEN 
FT IT 
FI 

IF G_AST [INDEX] . PR0C2SS0?.S_L_ASTE_N0 [I] OF THEN 
TEST = TRUE 
FI 

I += 1 



IF G_AST [INDEX] . N0_ACTIVE_DSPEND2NTS=? 
AMD IF TEST = FALSE THEN 

G_AS T [I NTZX] .UN I QTJF_II i := AVAIL AILS 
FI 

END CHECK TO? REMOVAL 



* The CEFC K_I F_CTHFRS _ACTI VF Procedure is called ty the 
Delete_entry orocedure. The procedure will check tc 
determine if a segment is active in any I_AST. If the 
segment is active, the variable Others_acti ve is set 
equal to true, otherwise it is set equal to false. 

JU 
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CHECK IF OTHERS ACTIVE PROCEDURE ( INDEX WORD 
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RETURNS ^ OTHERS, ACTIVE BYTE ' 

LOCAL I BYTE 
ENTRY 
I := e 
EG 

IE I = NO_OF PROCESSORS THEN 
0TF5RS_ACTIVE := FALSE 
RETURN 
FI 

IF G_AST [INEEX] .PROCESSORS L_ASTE_NO[l] O f THEN 
OTEERS_ACTIVE := TRUE 
RETURN 
FI 

I += 1 
OD 

END CHECK IF OTHERS ACTIVE 



% #, % #,« # 



The ACT IVE_IM_L_AS T Procedure is called 'ey the react- 
ivate procedure. The procedure will search the Seg- 
ment_#/Access_au th field of a segment to determine if 
the s°gmert is active in the L_AST. If the segment is 
active, the variable Check will he set equal to True 
and ^turned. 



ACTI VE_I N_L_AST PROCSFURE ( INLET WORD ) 

RETURNS f CHECK EYTE ) 

LOCAL I EYTE 
ENTRY 
I := 0 

CHECK : = FALSE 
DO 

IF I = MA X_DER_N0 ORIF CHECH = TRUE THEN 
RET TT RN 
FI 

IF L_AST [INDEX] . SEGMENT_NO_ACCESS_AUTH O e THEN- 
CHECK := TRUE 
FI 

I += 1 
OR 

END ACTIVE IN I AST 



f ^ 



^ %< 
^|% #|% #!% #|% #| 



US 



5:5 The r JPDATE_I. AST_ACCESS Procedure is called 'ey the Ir * 

* 'procedure. The procedure will set the read/write hit 

* of the appropriate se l ement_£/access_auth field of the * 

* L_£ST to a ore if the process has write access or to a * 

* zero if the process has read access. * 

* * ❖ 

mV *** %V mV %•# mV %*# %•# J# mV mV *V mV « ( # %•# mV mV m*# mV mV mV mV mV mV mV mV mV mV mV mV mV mV mV mV mV mV mV I 
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!JPDATE_L_AST_ACCESS PROCEDURE (INDEX WORD t ACCESS_AUTE FYTE, 

D5P_N0 EYTE ) 

LOCAL S EC-_N0 WORD 

ENTRY 

SEG_N0 := L_AST [INDEX] . SSG MENT _N0_ACCES S_AUTH [DSR_N0] 

IF ACC 7 SS_AUTK = WHITE THEN 

L_AST [INDEX] . SEGMSNT_NO_ACCESS AUTH [P2P. NC] : = 

SSG_N0 OH %(2)1 Z7M2Z2- 

ELS E 

L_AST [INDEX] . ? FGMEN'T_N 0_ACCESS_AUTH [rER_N0] : = 

?EG_N0 AND % ( 2 ) 21 1 1 1 11 1 1 
FI 

FND UPDATE L AST ACCESS 



f * 
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The SEAF.CF_G_AST Procedure is called ’oy the Activate 
procedure. The procedure will search the G_AST to 
determine if a passed segment's unique_id exists in 
the G_A?T . If the unique_id is found, a success code 
of found and the G_AST index are returned. If the 
segment is not found, a success code of not_found is 
returned . 



mV mV mV mV mV mV ml# mj 
#|m #^m # a m # 
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SEAHCH_G_AST PROCEDURE (SEG_ID I ON G WORD) 
RETURNS (SUCCESS ETTE, INDEX WORD) 

LOCAL I WORE 



— I'i X *L - 

I := 2 
I LOOP : DO 

IE I =^> G_A3T_LiyiT THEN 
SUCCESS := N0T_F0UNL 
INDEX := NUII 
RETURN 
FI 

IF C-_AST[I] . UNIQUE ID1 = SEG_ID THEN 
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SUCCESS 
INDEX : = 
RETURN 



:= FOUND 

I 



FI 

I += 1 



or 



2ND SEARCH S AST 



t u# y# u# % 

? *j% # 4 % *|* /(% #|« /|% * 



The CET_I_AST_INDEX Procedure is called by the Ua>e_ 
I_AST_entry procedure. The procedure will search the 
I_AST from top down until an available index is found. 
If an index is not found, a success_code of I_AST_full 
is returned. If an index is found, the index, and a 
success code of valid are returned. 



• *1* # 



* JU V*- 



C-ET_I_AST NO_INDEX PROCEDURE 

F.ET TT PN ( SUCCES S_CODS FITE , L_I NEZX 

LOCAL I WORD 

ENTRY 

SUCCESS _CODE := VAIID 
I := 0 



ILOOF : DC 

IF I => I AST_LIf / lT THEN 

SUCCESS_CODE := L_AST_? T JLL 
RETURN 



FI 

IF I _ A S T T 1 3 . r / EMOFY_ADDR = AV A HALLE 
L_I NDEX := I 

L_AST[I] . UEyOPY_ADD?. := ACTIVE 
RETURN 



FI 

I += 1 



OD 

END C-ET L AST NO INDEX 



WORE! 



THEN 
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The GET_G_AST_INDEX Procedure is called frojr the v| ake_ * 
G_AST_en t ry procedure. The procedure will search the 
G_AST from the top down until an available index is * 

found. If an index is not found, a success_code of * 

G_AST_full is returned. If an index is found, the index* 
and a success code of valid are returned. * 



* *•» »•» »•* ,t« » 
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GET G AST_INDEX PRO C E D U HE 

RETURN ( SUCC ESS_C0BS BYTE , INDEX VOPD) 

LOCAL I WORD 

ENTRY 

SUCCESS_CODE := VALID 
I := e 
ILOOP: DO 

IF I => G_AST_LIUIT TEEN 

SUCCESS _C CDS := G_AST_FULL 
FET T TF N 
FI 

IF G_A. ST [ I] . UN ICUID_IDi = NULL THEN 
INDEX := I 
RETURN 
FI 

I += 1 
OD 

END GET G AST INDEX 



% # 
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* The V AXI_G_AS T_EN TRY procedure is called fror the 

* Activate procedure. The procedure will obtain ar. 

* index into the G_*ST and enter the anpropriate data 

* from the alias table. The flag bits are set to not 

* written and not writable. The eventcounts and ticket 

* fields are set to zero. The processor_L_ASTE_* fields 

* are set to null. If the entry is successfully rrade, 

* a success_code of valid will be returned. 

'I* 



0 vV if i* ^ ju j# j# x o# j# o* « 

% ^ ^ «*|**|^ #|% #|« 0 



o# f 
? 



MAKE_G_A ST ENTRY PROCEDURE ( FAR_I NDEX WORD ,ENTRT_N0 WCP.C ) 
RETURNS ( SUCCESS_CODE BYTE, INDEX WORD ) 

LOCAL I WORD 

ENTRY 

SUCCESS CODE, INDEX : = GET G AST ENTRY 
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IF 



success_cods = valid teen 

G AST [INDEX] . UN I OUI D_ I D 1 := AI IA$_TA3IE . AI IAS_EN?RY [ 

ENTRY_NO] . UNIOUIB_ID 
G_AST [INDEX] ,GLOEAL_ADDR := ACTIVE 
G_AST [INDEX] .FLAG_BITS := G AST [INDEX] .FLAG_3ITS 

AND ( NOT ;\ r HITTEN_MASE ) 
G_A3T [INDEX] .FIAG_BITS :=G AST [INDEX] .FLAG_BITS 

AND ( NOT 7/R I TA 3 1 E_ M AS K ) 
G_AST [INDEX] . C-_A.STE_NO_FAR := ?AR_ INDEX 
G AST [INDEX] .NO_ACTIVE_IN_yEKO?.Y : = Z 
G~AST [INDEX] . NO_ACTIVE_DE?ENDENTS := Z 
G AST [INDEX] .SIZE1 := ALIAS_TASIE. ALIAS_ENTRY [ 

ENTE Y_NC ] .SIZE 

G_AST [INDEX] .PAGS_TABIZ_L0C1 : = 

A LIAS_TABLE. ALIAS ENTRY [ENTRY JvO] . FAC- _TABLE_ICC 
G_AS m [INDEX] . All AS_TABLE_LOCl : = 

AL IAS _7 ABLE. ALIA S_ENTR V [ENTE Y_NO] . AL I AS_TA3IE_L0C 
G AST [INDEX] .INSTANCE! := 0 
G~AST [INDEX] . INSTANCE2 : = Z 
G_AST [INDEX] .SZCtJENCER := Z 
I := 0 
HOC? : DO 

IF I = NO_OF_??OCSSSORS THEN 
EXIT 
FI 

G_AST [INDEX] . ?ROCESSORS_I_ASTE_NC [I] := N! T II 

I += 1 
OD 



SUCCESS_CODE := VALID 
FI 

END M AX E G AST ENTRY 
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The vl A r E_I_AS T_ENTRY Procedure is called fron the 
activate procedure. The procedure will obtain an 
index into the L_AST and enter the appropriate data. 
The nemory_addr field is set to active, the seamen t_ 
#/access_au th fields are initialized to zero, and 
the passed segment number is entered intc the ap- 
propriate location. If the entry is successfully 
made, a success code of valid is returned. 
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M AXE_L_AST_ENTRY PROCEDURE (DBR_N0 3YTE , SEG v ;ENT_NO WORD ] 
RETURNS ( STJCCFSS_CODE BYTE, L_INDZX WORD ' 

LOCAL I BYTE 
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SEG NO WORD 
ENTRY - 

VjCCESS_CODE, I_INDEX := GET_L_AST_INTEX 
IF SUCCESS COPE <> VALID THEN RETURN 
FI 

1_A$T fl_ INDEX] .MZMORY_ADDR := ACTIVE 
I~:= 2 



I_AST [L_INPZX] .SEGMENT_NO_ACCESS_AUTH [I] := 2 

I A = 1 

IF I >= MAX_DBR_N 0 THEN EXIT 
FI 



CD 

I_AST [I_INDEX] .SEGMENT 
ENT MAKE I AST ENTRY 



NO ACCESS /UTH [D3R 



NO] : =SEG V EN? 



NO 



*« *'* **» «i. < 



T »'» *'j *■ 



* .*« % 









The DEACTIVATS_ALI Procecure is called ty the 
Detete_entry procedure and hy the v ain_line 
procedure. The procedure will deactivate the 
deleted segment from all connected process' 
address space. The G_AST index and the I_AST 
index for the deleted segment are passed to the 
procedure. If the segment was successfully 
deactivated from all connected processes, a 
success code of valid is returned. 



* ‘P *0* 'I* » 
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DEACTI VATE_ALL PROCEDURE ( INDEX WORD, I_INDEX VOFI ' 
RETURNS ( SUCCESS_CODE BYTE ) 

10 CAL I BYTE 
ENTR V 

I := 0 
DO 

IF I = MA7._D3F._N0 THEN EXIT 
FI 

IF L_AST [L_INDEX] .$EGMENT_NO_ACCESS_AUTF fl] 

O ZERO THEN 

SUC CESS_CODE := DSACTIVAE ( I. INDEX ) 

IF SUCCESS_CODE <> S EG _DF ACTIVATED THEN 
RETURN 
FI 
FI 

I *= 1 
OD 

SU CCESS _C0 DE := VALID 
END DEACTIVATE All 
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The S IGNAI_OTHER_MEMORY_MANAGSF. Procedure is called 
by th Q In procedure. The procedure will signal 
a memory manager to move a segment from its local 
mpmory to global memory. When the segment is moved 
to global memory the procedure will signal all other 
connected memory managers to update their local 
databases. The global address for the transfer 
is passed. A success_code is returned to indicate 
the success of the operation. 
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SIGN AL_ 0 TKEP _ME MOR Y_MA N AGEE S PROCEDURE ( 

SEG_ INDEX WORD, ADD?. WORD ) 

KERENS ( SU C CES S _C 0 DE EYTE ) 

I OCA I 

PROCESS OR_N 0 BYTE 

FIPST BYTE 

L_ENTR’ r _NO WORD 
VA LIP_MS G BYTE 

M c G ARRAY [ V AX_MSC-_S I ZE BYTE] 

ENTRY 

FIRST := TRUE 
PR 0 CEsS 0 P._NC := 0 
DO 

IE FROCESSOR_NO = PROCESSOR_ID THEN 
PEOCESSOP_NC += 1 

FI 

IF PROC ESSOR_NO >= NO_OF PROCESORS THEN 
EXIT 
FI 

I_ENTRY_N 0 := G_AST [SEG_INDEY] .PROCESSOR I_ASTE_NO [ 

PROCFSSOR_lD ] 

IF I_ENTRY_NO <> N T ILI THEN 
IF FIRST = TRUE THEN- 
FIRST := FALSE 
IF PRO CES SOR_NO 
CASE F TEEN 

SIGNAL ( V?_ID , MEMORY_MANAGER_C , MGER, 
L_ZNTRT_NO , ADD?., G_AST [SEG_ INDEX] .SIZE * 
VF_ID , MS G := WAIT 

! **** CHECK I? VALID MSG *** ' 

VALIT_MSG := VALIDATE WAIT MESSAGE ( MSG ) 

FI 

ELSE 
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IF PROCESSOR NO 
CASE e THEN 

SIGKAK WF_ID, MEMO?. Y_MANAC-2R_C , UPDATE , 
L ENTP Y_NO , ADD?. , G_AST [S EG_I NTEX] . S I l v 
VP_ IE, MSC- := WAIT 

j ***** CHECK IF VAX IF MSG **** ! 

VALID_ M SG := V AIirATE_WAI T_MESS AC-F ( MSC- ^ 
FI 
FI 
FI 

F?OCSSSOR_NC += 1 

OD 

IF VAIID_MSG THEN 

SUCCES S_CODE := VALID 

ELS’ 7 

SrCCESS_COFE := INVALID 
FI 

END SIGNAL OTFE? MEMORY MANAGERS 
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The CRFATE_EMTRY Procedure is called by the 
M ain_line procedure. The procedure will create 
an entry irto the alias table and allocate sec- 
ondary storage for the created seerent. If the 
alias table does not exist, the procedure will 
create an alias table on secondary storage. 

A unique_id is assigned to the segment and the 
appropriate data is entered into the table. 

If the function is successfully ~orrpleted, a 
succe?s_code of se^nen t_crea ted is returned. 



4 # 4 # %*# 4^ JU 4 # 4^ «JU 4# 4# «, 
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RE ATE ENTRY 



return: 



PROCEDURE ( FAR_ INDEX WORD 
SIZE WORD, CLASS BYTE ) 
SUCCESS CODE IYTE ^ 



ENTRY NO WORD , 



LOCAL ?AGS_TA5LE_L0C WORD 

ELKS WORD 



ENTRY 

3LKS := SIZE / 5IE_SIZE 

IF G_AST [FAR INDEX] .G_ASTE_NO_FAR <> ZERO THEN 

STTCCFSS_COLF := CF,EATE_AL AIS _TA.ELE( FA?_I NFEX > 
IF SUCCESS CODE <> VALID THEN 
RETURN " 

FI 
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!ND 



II 

SUCG3SS_C0D3 := FEa.D_ALI A5_TABLI ( 

C-_AST [?AR_ INDEX] . All AS_TABLE_L0C1 , #ALIAS_TA2I Z ) 
IF ? r CClS $_CODE O VALID TFIN 
RETURN 
II 

IF ALIAS _TABLE . AL I AS _EN TRY [E NTRl_N0] . UNIC U I D_I D O f 
THEN 

SUCCESS _C0DE := DU?LICATE_ENTRI 
RIT TT ?N 
II 

PAGE_TABLE_LOC , SUCCESS_CODS := ALLOC_SSC_STORAC-E( 

BLKS ) 

II SUCCES S_C0DE <> VALID THEN 
RETURN 
II 

ALI AS_TABLE . AL I A S_ENT?Y [ENTRY _N0] .UNIQUE ID, 

S T JCC2SS_C0DE := GET_UNIO_ID 
II SUCCESS _C0DI <> VALID THEN 
RETURN 
II 

ALIAS _?ABLE. ALIAS_ENTHI [ENTRT_K0] .SIZE SIZE 
ALI AS _T ABLE . ALIA S_EN TRY [ENTRY_N0] .CLASS := CLASS 
A LIAS_TABLS . AL IAS _ENTRI [EN?RY_N0] . FAGS_TABLE_LOC : = 

PAGE_TABLE_LOC 

A L I A S _ T A B L E . A L I A S _ E N T R T [ E N T R T _ N 0 ] . A L I A S TA2II_L0C := 2 

Sl T CCESS_CODE := WRITE_ALIAS_TABLE (G_AST"[PAR_I MUX] . 

ALI AS_TABLE_LOC , #AL IAS_T ABLE ) 

IF S r JCCESS_CODE = VALID THEN 
SUCCESS_CODE : = SEG_CREATED 
II 

CREATE ENTRY 









S,J 5|5 #,• v 



The DELETE_ENTRY Procedure is called by the v ain- * 
line procedure. The procedure will recove a segment 
from secondary storage by deleting its entry in its s|i 
mentor segment's alias table and deallocating its * 

allotted secondary storage. Before the segment is * 

deleted, the G_A.ST is checked to ensure that no other * 
process holds the segment active, and that the segment * 
is not a mentor segment. If the segment is a mentor * 

segment, deletion is net allowed. If the segment is * 

active, those processes will b<= signaled to deactivate * 
the procedure. When the segment is deactivated, it * 

will b<= deleted. If the deletion is successful, a 
success code of see deleted will be returned. * 
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DELETE ENTRY PRC C SCURF ( ?AR_INDEX WCRB , ENTRY_NC WORD ’ 
RETURN’S ( SUCCESS_COEE BYTE ) 

LOCAL I _I NDEX WORD 
INC EX WORT 
I EYTE 

AI IAS_TABLE_SMPTY BITS 
OTHERS _ACTIVE EYTE 

ENTRY 

IE G_AST fPAR_Ii\DEX] . ALI AS_TAELE_LOCl O NULL THEN 

SUC CES S _CCDF := REAE_AL AI S_TAELE ( G_AST [PAP_I NDEX] . 

AIIAS_TABIE_L0C1 , #AL IAS _T ABIE ) 

ELSE 

SUCCESS_COrE := NO_CHILr_TO_CELETE 
FI 

IF SUC CESS _C0DE O VALID THEN 
RETURN 
El 

ALI AS_TA3LE_EMPTY := CEECH_I J_ALIAS_S M PTY 
IE A I IAS_TAELE_Ei v ?TY = TRUE THEN 

SUCCSSS_CODE, INDEX := SEARCH_G_AST ( 

AL IAS_T® ELE. ALI AS_ENTRI [ENTRY_N0] .UNIC’ T E_ID ) 
IF SUC CES S_C0DE = FOUND THEN 

L_I NDEX := G_AST [PAR_INDEX] .PROCESSORS _L_ASTE_N0 [ 
PROCESS 0R_ID] 

IE L_INDEX O NULL THEN 

SUCCESS_CODE := DE ACT IVATE_ALI ( INDEX , L_I NDEX ) 
IE SUCCESS _C0DS <> VALID THEN 
RETURN 
FI 
El 

OTHERS_ACTI VE := CHECK_IE_OTFERS_ACTIVE 
IF OTHE?.S_ACTIVE = TRUE THEN 
S IGNAL OTHERS _T0_DE AC T I VA.TE_ALL 
FI 
El 

DEIETE_S EG ( SNTRY_N0 ) 

ALIAS _TAELE . AL IAS _EN TRY f ENTRY _N0] . UN ICUE_ IT := C 
$UCCSSS_CODE := WR.ITE_ALIAS_TA.3IE ( G_ AS T TRAP _I NDEX] . 

ALIAS_TABLE_L0C1 , *ALIAS_TAEIE '/ 

IE S TT CCES S_C0PE = VALID THEN 
SUCCES S _CODE := SEG_DELETED 
El 

ELSE 

SUCCESS _C ODE := DE^ENDEN TS_EXI ST 
El 

END DELETE ENTRY 
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The ACTIVATE Procedure is called tv the Main_line 
procedure. The purpose of activate is to add. a 
segment to the user's address space. The procedure 
is passed the segment_#, the parent's handle, and 
the entry number into the alias table for the 
segment. The procedure returns the size. 
class., and the handle for the activated segment 
The G_AST is searched to determine if the segnert 
is already active. If the segment is active and 
not in the L_AST, an entry is made in the L_AST 
and the G_AST is updated. If the segment is active 
in both the G_AST and the L_AST, the entries are 
updated. If the segment was not active, entries 
are made in both the G_AST and the L_AST. 

If the operation was successfully completed, a 
success_code of seg_activated is returned. 
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ACTIVATE PROCEDURE (DP?_N0 PYTE , PAR_IND2X WORD, 

ENTRY_N0 WORD, SEGMENT NO PETE ) 

RET TT R N c ( SUCC?SS_COrE PTTE , G_AST_HANIIE FANE IE . 

CLASS PYTE, SIZE WORD ) 

IOCAI I_INDEX WORD 

INDEX WORD 

ENTRY 

IP G_AST [PAR_ INDEX] . AIIAS_TAPIE_IOCl O ZERO TEEt’ 
S1 T CCESS_CCDE := READ_AII AS_TAILS^G AST [PAR_I NDEX] . 

AL I AS _T API E_L DC 1 . #AII A S_TAPIE ) 

ELSE 

SUCCESS _C0E? := NO_LEAF_EXIS T 
FI 

IE SUCCZS S_C0DE <> VALID THEN 
?ET TT P..N 
PI 

S TT C CES S_C ODE , INDEX := SE ARCH_G_AST ( 

AL IAS_TAPLF .ALIAS _ENTRT [ENTRY_N 0] .UNICUE ID ' 
IF SUCCESS_CODE = POUND THEN 

L_I NDEX := C-_AST [INDEX] .FROCESSORS_I_A STE N0[ 

PP.OCESSOP._irT 

IF L_IMDEX O NULL THEN 

L_AST[L_INDEX] .SEGMENT NO_ACCESS_AUTH [D3R_N0] := 

SEGMENT_N0 

ELSE 

SUCCES S_C0DE , L_INDEX := MAXS_l_AST_ ENTRY ( 

DER_NO , SEGMFNT_NO ) 

IF SUCCSSS_CODS O VAIID THEN 
RETURN 

TT 
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G AST riNEEX] .PROCESSORS I ASTE_NO [PFCCFS SOR_I D] 

:= L“I NDEX 
FI 

IF C-_AST [INTEX] .ALIAS _TAEI3_L0CJ = NULL THEN 
G_AST [PAR_INDSX] ,NO_DSpFNDENT?_ACTIVE -= 1 

FI 

FI C F 

SUCCFS S_C ODE , INDEX := MARE_G_A3T_ENTP.Y ( FMT?.Y_NO) 
IF SUCCESS CODE = G_AST_FUII TFFN 
RETURN 
FI 

SUCCESS _C ODE, L_INDEX := YAXS_L_AST_EN TRY ( 

PA R_ I NDEX, ENTRY NO ' 

IF S UC C E S S _ C 0 DE = L_AST FULI THEN 
RETURN 
FI 

G_ AST T INDEX] .PP0CESS0R3_L_ASTF_N’0 [PPOCESSO?_ID] : = 

I_ INDEX 
FI 

SUCCESS_CODE := SSG_ACTIV ATED 

SIZE := ALIAS_TABLE.ALIAS_ENTPY[ENTRY_NO] .SIZE 
CLASS := AIIAS_TABLE. All AS_ENTPY [ENTRY NO] .CLASS 
G_AST_EANDIE .UNICUE_ID2 : =G_AST [ INDEX] .TJNICUE_ID1 
C- AST HANDLE . INDEX := INDEX 
END ACTIVATE 
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The S’v A?_OUT Procedure is called by the Nain_lire 
procedure or the Deactivate procedure. The 
procedure will rerove a segment from nain memory 
ard store it on secondary storage. The procedure 
is passed the process' DPR_# and the G_AST index 
for the segment to be swapped out of memory. 

A success_code is returned to indicate the success 
of the operation. The procedure removes the 
segment from the process' M NlU_Ima,?e and if not 
shared, it is returned to secondary storage 
and memory deallocated. Shared segments remain in 
memory until all processes have swapped the segment 
out of main memory. 
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SV/A?_0UT PROCEDURE ( DER_N0 BYTE, INDEX WORD ' 
RFT TT RN? ( SUCCES S_C0DF BYTE ) 

LOCAL 3IKS WORD 

L_ INDEX WORD 
SFG MO WORD 
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ENTFY 

PIES := G_iST [INDEX] .SIZE1 / 3IX_SIZE 

L_INDEX : =G_AS T [INDEX] .FROCESSOR_L_ASTE_NO [PROCESSOR, ID] 
SEG_MO := L_AST[L_INDEX] . 5EGPENT_NO_ACCES S_AUTH [M? NO] 
E?.EE_'P TJ OCES S_V IRT T JAL_CORE ( ELKS ) 

DEI ETE MMU_SNTRY ( DEF_NO, SEG_NO ) 

G_AST[IMDEX] .NO ACTIVE_IN MEMORY -= 1 

I? (mmu_image [der_no] .sdrTseg_no] .attributes and 

WRITTEN MASK) O 0 THEN 

G_AST [INDEX] .PI AG_IITS := G_AST [INDEX] .FI AC-_PITS OR 

WRITTEN PA SK 



FI 

IF 



ELSE 



G_AST[INEEX] . C-I0BAI_ADDR = NULL THEN 
IF G_AST T INDEX] .M0_ACTIVE IN_PE v 0RY = 2 A NDI F 
(G_AST [INDEX] .FLAG_BITS AND WRITTEN_MASK ) O 0 
THEN 

SUCCES S_C0DE := WRITE_SEGMENT ( G_AST [INDEX] . 

PAGE_TABLE_LOC , L_AST [L_I MDEX] 
MEmORY_ADER ) 

IF S T JCCESS_CODE <> VALID THEN 
RETURN 
FI 

FREE_L0CAL_3 IT_PA? ( I_AST[L_INDEX] . PEM0r.Y_AEEF , 

BIDS ) 

ELSE 

IF G_AST [INDEX] .NO ACTIVE_IN_MEMOPY = 0 THEN 
FREE_L0C AL_BIT_MAF ( L AST [L_ INDEX] . 

PEPORY_ADBR, DDKS ) 

FI 

FI 

IF G_AST [INDEX] .NO_ACTIVE_I N_ME M 0RY = 2 ANDIF 
(G_AST [INDEX] .FLAG_BITS AND WR ITTEN_MASX ) O 2 THEN 
SUCCESS_CODE := WRITS_SEGPENT ( G AST [I NDFX] . 

PAGE_TABLE_L0C1 , G_AST [ IN DEXj . GLOBAL _ADER 
IF SUCCESS _C0DE O VALID THEN 
RETURN 
FI 

FRES_GLCEAL_BIT_MAP ( G_AST [INDEX] . GLOEAL_ADDR , 

DIES ^ 

ELSE 

IF G_AST [INDEX] . N0_ACT IVE_IN_‘ / EMORY = 0 THEN 
FREE_GLOIAL EIT'_MA ? ( G_AST [INDEX] . C-LOEAL _ADDR 



3IHS ' 



.FI 



FI 



El 



SUCCESS_CODE := SWAPPED OUT 
END SWAP OUT 
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The DEACTIVATE Pro cedu re is celled by the 
the Main_line procedure, the Deactivdte_dll 
procedure, or the Delete_entry procedure. 

The purpose of deactivate is to remove a segment 
from a process' address space. The segment is 
removed by deleting the segment number from the 
L_AST. If no other processes have the segment 
active and no children are active, the entry 
is removed from the L_AST and the G_A.5T. 

The process' DBR_# and the deactivated segment's 
G_AST index are passed to the procedure. A 
success_code is returned to indicate the success 
of the oneration. 






J- J# %>* U# J# ^ JU ^ ^ ^ V# %># %l# v*- %># 4# *4# 4# 4# 4# f 

r|« <|<% >|% ^|> ^ f 



DEACTIVATE PROCEDURE ( DBR_N0 BYTE, INDEX WORD ) 

RETURNS ( St T CCESS_CODE BYTE ) 

LOCAL L_IN DEX WORD 

SEG_N0 BITE , 

CHECK BYTE 

PAR_INDEX WORD 

ENTRY 

?AR_I NDEX := G_AST [INDEX] ,G ASTE_NO_PAR 

L INDEX := G AST[INDEX] .PROCESSOR L_ASTE NO [?R0CES30R_ID] 
SEG_N0 := L_AST [L INDEX] . 3EGMENT_N0_ACCSSS_AUTK [DBR_NC] 

IF G AST [INDEX] .NO_ACTIVE_IN_MSMORY O 0 THEN 

IF (MMU_IMAGE [DBP_N0] .S DR [S EG_N0] .ATTRIBUTES AND 

I NjMEMORY MASK) = ZERO THEN 
SUCCES3_C0DF := SWAF_CUT 7 CBR_N0, INIEX ) 

It S T JCCESS_CODS O SWAPPSD_OUT THEN 
RETURN 
FI 
FI 
FI 

L AST [L_INDEX] .SEGMENT_NO_ACCESS_AUTH[DBR_NO] : =• 0 
CHECK := ACTIVE_IN_I AST ( L_I NDEX ) 

IF CHECK = 0 THEN 

L_AST[L_INDEX] .MEMORY ADDR := AVAILABLE 
FI 

IF PAR_I NDEX <> 0 THEN 

G_AST [PAR_INDSX] .NO_ACTIVS_DEPENDENTS -= 1 
CHECK_FOR_REMOVAI ( ?AR_INLEX ) 

FI 

CHECK_FCR_REMOVAL ( INDEX ) 

S T JCCESS_CODE := SEG_DEACTIVATED 
END DEACTIVATE 
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The MOVE_TO_GLOBAL Procedure is called by the 
i M ain_line procedure. The procedure is called to 
to move a shared and writable segment to global 
memory. The procedure is passed the L_AST index, 
the size, and the global address for the move. 

A. success_code is returned to indicate the 
success of the operation. The procedure locates 
the segment in its local memory, transfers the 
segment to global memory, and deallocates the 
local memory. 
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M0VE_T0 GLOBAL PROCEDURE ( L_INDEX WORE, GLOB AL_ADDR 

ADDRESS, SIZE WORD ) 

RETURNS ( S UCCESS_CODE LTTE ) 

LOCAL SEG_N0 BYTE 
I BYTE 

ENTRY 

MEMCRYJ'OVE ( L_AS T [L_I NDEX] . ME v OR Y_ADDR , GLOB AL_ALLR , 

SIZE ) 

L_AST [L_INDEX] ,ME. v IORY_ADDR := ACTIVE 
I := 0 
DO 

IE I = MAX_DBR_N0 THEN EXIT 
FI 

SEG_N0 := L_AST [L_INDEX] . SEGMENT_NO_ACCESS_AUTF [I] 

AND %(2) 011 11111 

IE SEG_N0 <> 0 ANLIF ( PttU_IMAGE [I] . STR [SEG_NC] . 

ATTRIBUTES AND I N_KENORY_MASX ) = ? THEN 
MMU_IMAGE[I] .SDR[5SG_N0] .FASE_ADDR := GLOBAL ADD?. 
FI 

I += 1 

OD 

FREE _IGCAL_BIT_MA? ( L AST [LI NDEX] .MEMOP.Y_A.DLR . BLKS ) 
SUCCESS _CODS := VALID 
END "OV TO GLOBAL 
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The SWAP_IN Procedure is called by the i v iain_line 
procedure. The procedure will transfer a segment 
from secondary storage to main memory. The procedure 
is passed the process' DB?_#, the segment's G_AST 
index, and the authorized access to the segment. 

A success_code is returned to indicate the 
success of the operation. ( successful = swapped_in ' 
If the segment is not already in memory, the appro- 
priate memory is allocated and the segment is trar.s- 
fered to the allocated memory. If the segment is 
writable and shared, the segment is transferpd irto 
global memory. 



* .1. »•* 
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SWA? IN PROCEDURE ( INDEX W0RD,PBR_N0 BITE , ACCES S_AUTH BITE) 
RETURNS ( SUCCESSIONS BYTE ) 

LOCAL 5LKS WORN, 

TEST BYTE 
SEG_N0 BYTE 
L_INNEX WORD 
I ASE_ADrR ADDRESS 

ENTRY 

BLKS * : = G_AST [INDEX] .SIZE / BLK_SIZE 

L_IN’DEX :=C-_AST [INDEX] . PROCESS OR_L_ASTE_NG [?ROCESSO?_IE] 
SEG_NO := L_AST[L_INDEX] . SEG.YSNT_NO_ACCESS_AUTH [DBR NO] 
SUCCESS _CODE := CFECK_KAX_VI RTUA L CORE ( DER_NO , BLKS ] 
IE SUCCESS_COLE = VIRTU AL _C 0RE_FULL TFEN 

RETURN 
El 

G_AST [INDEX] . NO_ ACTIVE I N_ MS MORE += 1 
IE ACCESS_A r JTK = WRITS THEN 

G_AST [INDEX] .ELAG_BITS : = G_AST [INDEX] .ELAG_BITS OR 

WR I TABLE _YASK 

El 

IE (G_AST [INDEX] .FLAG_BITS AND WR ITABLE_MASH ) = £ 

OFIE G_AST [ INDEX] . NO ACTIYE_IN ^EMOP.I <= 1 THEN 
TEST := CHECH_LOCAL_MENORY ( L_ INDEX ) 

IF TEST <> IN_LOCAL_MEYiORY TFEN 

SUCCESSIONS, EASE ADDR := AI,LOC_LOCAL YEYOF.Y ( ELKS ) 
IF SUCCESS CODE = L0CAL_K5y0RY_FULL THEN 
RETURN 
FI 

SUCCESS_CODE := READ_SEC-MENT ( G_AST [INLFX] . 

FAGE_TABLE_LOCl , LASE_ADDR ) 
IF SUCCESS CODE <> VALID THEN 

?REE_LOCAL_EIT_YAP ( 3 AS E_ ADDR, EIHS ) 

RETURN 

FI 
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L_AST [L_INDFX] . MEMORY _AD IF, := BASF_ADDR 



ELSE 

BAS V _ADDR 

FI 



L_AST[L_ INDEX] . [dEyORY_ADDR 



ELSE 

IF G_AST [INDEX] . GLOBAL_ADDR = NULL THEN 

SjCCESS_CODE, EASE ADDR := ALLOC_GLOPAL_MEMORY f 

EIaS ) 

IF SUCCESS CODE = GLOBAL_MEMORY_FULL TFFN 
RETURN 
FI 

IF TEST = IN_LOCAL THEN 

SUCCESS_CODE := MOVEJTO GLOBAL ( L_INDEX, 

3ASS_ADDR,C-_AST [INDEX] . SIZEl ' 
IF SUCCESS CODE <> VALID THEN 

FREE_GL03 AL_BI T !*A? ( BAS E_ADDR , ILFS 
RETURN 
FI 
ELSE 

SUC CES$_CODS : = 

SIGNAL_0TESR_MSM0P.Y_MANAGE?.S (INDEX ,BASS_ADDR ) 
IF SUCCESS_COl E O VALID THEN 
RETURN 



FI 

FI 

ELSE 

BAS E_ A DDR := G_AST [INDEX] .GLOBAL_ADDR 
FI 
FI 

UFDATE_MMU_IMAGE ( DBR_NO , SEG NO, 3ASE_ADLR, ACCESS_AUTH , 

ELKS ) 

U?DATE_L_AST_ACCSSS ( L_I NDEX , ACCESS_AUTH, DBF._NC ) 
SUCCESS CODE := SNAPPED IN 



END SWAP IN 
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The N’0VE_T0_L0CAL Procedure is called by the yein_ 
line procedure. The procedure is called when * 

a segment no longer needs to he in e-lobal memory 
and can he moved to local memory. The procedure 
is passed the L_AST index, size, and global address * 
of the segment to he moved. A success_code is returned * 
to indicate the success of the operation. * 
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MOVE_TO_LOCAI PROCEDURE ( L_I NDEX WORD, C-LOBAL_AEDR 

ADDRESS, SIZE WORD ^ 
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RETURN 

LOCAL 



IT*' 



:nc 



( SUCCESS COLE 
PAS E_ADD HESS ADDRESS 
SFC-_NO BYTE 
I BYTE 

BLKS BYTE 

ENTRY 

BLKS := SIZE / SLK_SIZ2 

SUCCESS_CODE, BASE_ADDRESS := ALLOC_LOC AL_MEMOFY ( LIKE ) 
17 ST;CCESS_COrS <> VALID THEN 
RETURN 
FI 

MEMORY_MOVE ( GLOBAL_AL£R , I ASE_AEDRESS , SIZE ) 

L_AST [L_INDEX] .mEMORY_ADDR := B AS E_ADDRESS 
I := ? 

DO 

IF I = MAZ_DBR_NO THEN EXIT 
FI 

SEC-_NO := L AST [L_I NDEX] . SSGMENT_NO_ACCESS_AUTF [ I] 
AND % (2)01111111 

IF SEG NO <> E ANDIF (MHU_ IMAGE [i] . SDR[SEG NOl . 

ATTRIBUTES AND IN MEMOR Y_MASX ) = e THEN 
MMU_IMAGS[I] .SLRlSSG N0T.BASE_ADDR:=BASE_ADDRESS 
FI 

I += 1 
OD 

SUCCESS CODE = VALID 
MOVE TO“LOCAL 



! 



» 
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The UFDATE Procedure is called by the Main_line 
procedure. The procedure is called to update the 
MMU images of process' connected to a segment 
that was moved to global memory by the Move_to_glohal 
procedure. The procedure is passed the L_AST irdex, 
the size, and the global address of the segment 
that was moved to global address. A success_code 
is returned to indicate the success of the operation. 



UPDATE PROCEDURE ( L INDEX WORD, GLOB AL_A DIR ADDRESS . 

SIZE WORD ) 

RETURNS ( SUCCESS_C0D3 BYTE ) 

LOCAL SEG_N0 FYTE 
BLKS BYTE 

I BYTE 

ENTRY 
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DO 



IF I = MAX_DBR_NO THEN EXIT 
FI 

SEG_N’0 := L_AST [L_I NDEX] .SEGMENT_NC_ACCESS_AUTH [Ij 
AND £(2)01111111 

IF SEC-_NO <> e AND 1 1 (MMU IMAGE [I ] .S DR [SEG NC] . 
ATTRIBUTES AND IN _MEMORY~MASK ) = 0 THEN 
MMU_IMAGE[I] . SDR [SEG_NO] .BAS E_ADDR := GLOBAL _ADDR 
FI 

I += 1 



OD 



ELKS := SIZE / ELK SIZE 

F 7 ?EE_LOC AL_BIT_MA?r L_AST [L_INDEX] . MEMORY_ALD? , ELKS ) 
L_AST [L_INDEX] 7 hZM0RT_ADDR : = ACTIVE 
SUCCES S _CODE := VALID 
END UPDATE 



MAIN lin: 



cod: 



$ SECT I ON VAIN 



MAI N_LI NE PROCEDURE 

LOCAL FUNCTION BYTE 

ARGUMENTS ARRAY [ ??? 3 Y TE] 

MSG ARRAY [MAXjMSG SIZE BYTE] 

7P_ID EYTE 

SUCCES S_CODE BYTE 

ENTRY 

I NITI ALI ZE_?ROCFSSOR LOCAL_?ARI AELES 
DO 

CHECK MSG CUEUE 
V ?_ I D . MSG := WAIT 

j #** VALIDATE THE MSG FROM *AIT 



FUNCTION, ARGUMENTS := 


FUNCTION 




case 


CREATE ENTRY 


THEN 


CASS 


DELETE_FNTRY 


THEN 


CASE 


ACTIVATE THEN 


succ: 


CASE 


DEACTIVATE 


THEN 


CASE 


S WAP_IM 


I 


CASS 


S'.vAP_OUT 





CREATE SNTRY( ARGUMENTS) 
SUCCFSS_CODE := 
DELETS_ENTRY( ARGUMENTS ) 
ESS _C ODE, HANDLE, CLASS ,SIZF 
ACTIVATE ( ARGUMENT S ) 
SUCCESS_CODE := 
DEACTIVATE (ARGUMENTS ) 
THEN SUCCESS_CODE := 
SWAP_IN (ARGUMENTS ) 

THEN SUCCESS_CODF := 

SWAP OUT (ARGUMENTS ) 
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CASE MOTE TO LOCAL. THEN SUCCESS CODE : = 

" " M07E_T0_L0CAL ( ARGUMENTS ) 

CASE MC7S_TC_C-I ORAL THEN SUCCESS_CODE : = 

MOVE_TO_GLOBALf ARGUMENTS ) 
CASS UPDATE THEN SUCCESS_CODS := 

UPDATED ARGUMENTS ) 

CASE DEACTIVAE_ALI TEEN SUCCESS CODS := 

D S A C T I V A T E _ A I L ( A R C- U M E N T S ) 
FI 

SIGN AI ( VP_ ID , SUCCESS_CODE, ARGUMENTS ) 

OD 

END MAIN_LINS 

END MEMORY MANAGER PL2 SYS MODULE 
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APPENDIX 3 - PLZ/ASM SOURCE LISTINGS 



! 

! 

r 

! 



£##>}£#### a;:##### a}: J 



THE PLZ/ASM MODULE WAS WRITTEN TO PROVIDE SUPPORT FOR ! 
THE SWAP IN TEREAD [APPENDIX 3] . TEE VALIDITY OF THE I 
CODE HAS NOT BEEN THOROUGHLY TESTED, NOR HAS IT BEEN ! 
OPTIMIZED. THE CODE SIMULATES SECONDARY STORAGE IN ! 
MAIN MEMORY, AND WAS NOT INTENDED TO BE USED IN AN ! 
ACTUAL SYSTEM IMPLEMENTATION. ! 

5*c;l€## ########£##### ######££######## #£############ I 



M MGR 2 MODULE 



i * * # * VERS. 1.0 * * * * ! 



CONSTANT 



FALSE 

TRUE 

AVAILABLE 

ACTIVE 

ZERO 

NULL 

NULL PAGE 

HBUG" 

MONITOR 



0 

1 

0 ! AST ENTRY AVAILABLE ! 

1 l AST ENTRY ACTIVE ! 

0 

%0000 

0 

%A900 
£059 A 



! SUCCESS CODES ! 
INVALID := 0 

VALID := 1 

FOUND := 2 

NOT_FOUND := 3 

SWAPPED, IN := 4 

SWAPPED_OUT := 5 

SEG ACTIVATED := 6 
SEG DEACTIVATED := 7 
SEG CREATED := £ 

SEG'DELETED := 9 

LEAF SEG EXISTS := 10 
NO LEAF_EXISTS := 11 
G_AST_FULL := 12 

L_AST FULL := 13 

IN_LCCAL MEMORY := 14 
NOT IN LOCAL MEM := 15 
LOCAL MEMORY_FULL := 16 
GLOBAL_MEM_FULL := 17 
VIRTUAL CORE FULL := 18 
DUPLICATE ENTRY := 19 
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NO CHILD TO_DEL := 20 
SEC STOR'FULL := 21 
DISK_ERROR := 22 

ALIAS DOES NOT EXIST := 23 



attribute-masks 
READ MASK 
WRITE MASK 
CHANGED MASK 
IN_MEMORY MASK 
CLEARED 

AUTHORIZED ACCESS 
READ 
WRITE 
EXECUTE 



= % ( 2)11111110 
= %( 2 ) 00000001 
= % ( 2 ) 01000000 
= %( 2 ) 03000100 
= 0 
j 

= 0 
= 1 

= %{ 2 ) 00001000 



! CLEAR ATTR ! 



! G AST FLAG BITS FIELD MASKS ! 

WRITAELE MASK : = %(2)00000010 

WRITTEN_MASK := %(2)00000100 



! DESIGN PARAMETERS 
BLK_S IZE 
MAX PAGE_S IZE 
NO_OF PROCESSORS 
MAX_ DBR_ NO 
G AST LIMIT 
L_AST_LIMIT 
MAX ENTRY NO 
NO_SEG DESC_REG 
FST POSS FREE.3LK 
DISK_MEM BASE 
MAX.POSS D_BLKS 
GLOBAL MEM BASE 
MAX POSS_GlBLKS 
LOCAL_MEM BASE 
MAX_POSS L BLKS 
DISK_EIT'MAP_LOC 

TYPE 

ADDRESS 
ALIAS EEADER 



SEG_DESC_REG 



ALIAS 



= 128 

= BLK_S I ZE/2 
= 1 

= 4 ! EVEN NC. OF DER_#'S ! 

= 16 ! MAX ENTRIES IN G_AST ! 

= 16 ! MAX ENTRIES IN L_AST ! 

= 10 ! SIZE CF ALIAS TABLE ! 

=3 ! NO. OF SEGMENT/PROCESS! 

= 1 

= %9000 
= 96 
= %8000 
= 32 
= %6000 
= 64 
= 0 

WORD 

RECORD [ 

SEG_PAGE TABLE LOC WORD 
?AR_ ALIAS _TA3LE_L0C WORD ] 

RECORD [ 

BASE_ ADDR ADDRESS 
LIMIT BYTE 

ATTRIBUTE BYTE ] 

RECORD [ 

UNIQUE.ID WORD 

CLASS WORD 

SIZE WORD 
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PAGE TAELE LOC WORE 
ALIAS_TABL3_LOC word ] 

MMU RECORD [ 

SDR ARRAY [MO SEG D2SC_R£G 
SEG.DESC REG] 
BLKS USED WORD 

MAX_ELKS WORD] 

GLOBAL 

! ^SECTION G_ DATA ! 

GLOBAL_MEM BIT_MAP ARRAY [MAX POSS G BLKS/16 WORD] 
G_AST_LOC2~ BYTE 

! ^SECTION L_ DATA ! 

MMU_ IMAGE ARRAY [MAX DBR_NO MMU] 

LOCAL MEM_3IT_MAP ARRAY [MAX POS5_L BLKS/16 WORD] 
ALIAS TAELE RECORD [ EEADER ALIAS_EEADER 

ALIAS.ENTRY ARRAY 
[MAX_ENTRY NO ALIAS] ] 
DISK BIT MAP BUFF ARRAY [6 BYTE] 

PAGE'TABLE BUFFER ARRAY [BLK SIZE BYTE] 

INTERNAL 

COMPACT L PROCEDURE 
ENTRY 

END COMPACT L 



COM?ACT_G PROCEDURE 
ENTRY 

END COMPACT.G 
GLOBAL 

ALLOC_LOCAL_MEMORY PROCEDURE 

J 5}c 5 J 5 sjc sjc sjc »{• ?p i{c »p 3{s ip ijt ip ip )p ijc ijC ip ip ip ip ijc ip ip ip ijc ip ip ip ip ip ijc ip | 



! PASSED PARAMETER ! 
! R0 = BLKS OF MEMORY ! 
! RETURNED PARAMETERS ! 
! R0 = SUCCESS CODE ! 
! R1 = BASE_ADDR ! 
! LOCAL VARIABLES ! 
! R0 = BLKS ! 
! R10 = BIT MAP INDEX ! 
! Rll = COUNTER FOR BIT ! 
! R12 = BIT MAP WORD ! 
! R13 = WORKING REGISTER ! 



140 



LOCAL BLKS WORD 

IS COMPACTED BITE 
FILLER2 BITE 

ENTRY 

LD ELKS , R0 

LDB IS COMPACTED, #FALSE 
LD R10, #ZERO 
DO 

CP R10 , #( MAX_P0SS_L_3LKS/16 ) 

IF EQ TEEN 

CPB IS COMPACTED, #FALSE 
IF EQ 'THEN 

CALL COMPACT L 
LD R10 , #ZERO 
LDB IS_COM?ACTED , #TRUE 

ELSE 

LD R0 , #LOCAL MEMORY FULL 
RET 
FI 
FI 

LD Rll , #ZERO 

LD R12 , LOCAL_MEM_B IT MAP(R10) 

DO 

BIT R12 , Rll 
IF Z TEEN 

DEC R0, #1 

ELSE 

LD R0 , BLKS 
FI 

CP R0 , #ZERO 
IF EQ THEN 
LD El, R10 
MULT RR0 , #16 
ADD El, Rll 
SUB Rl, BLKS 
MULT RR0 , #3LK_S IZ E 
ADD El, #LOCAL MEM BASE 
LD R0 , #VAL I D 
LD R13 , BLKS 
DO 

LD R12, LOCAL MEM_BIT MAP(R10) 

DO 

SET R12 , Rll 
DEC R13, #1 
DEC Rll, #1 
CP R13, #ZERO 
IF EQ TEEN 

LD LOCAL_MEM BIT.MAP (R10 ) , R12 
RET 
FI 
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CP Rll, #ZERO 
IF EQ THEN 

LD LOCAL MEM 3IT_MAP (R10 ) , 
LD Rll, #15 
DEC R10, #1 
EXIT 



FI 

OD 

OD 

FI 

INC Rll, #1 
CP Rll, #16 
IF EQ THEN 

LD Rll, #ZERO 
EXIT 
FI 
OD 

INC R10 , #1 
OD 

END ALLOC_LOCAL MEMORY 



FREE_LOCAL_BIT_MAP PROCEDURE 



! PASSED PARAMETERS ! 
! R0 = BASE ADDR ! 
! R1 = BLKS~ ! 
! LOCAL VARIABLES ! 
! R10 = COUNTER FOR BIT RESET ! 
! Rll = BIT MAP INDEX ! 
! R12 = BIT MAP WORD ! 



I £ # s)t ## sjs ajs ## # $5}C s*### Jjt * £ # #### ## # $ J 



ENTRY 
CLR R10 
LD Rll, R0 

SUB Rll, #LOCAL MEM BASE 
DIV RR10 , #BLK SIZE-16 
DO 



R12 , 


, LOCAL_MEM 


_BIT 


_MAP ( Rll ) 




RES 


R12 


, R10 








DEC 


HI, 


#1 








CP 


HI, 


#ZERO 








IF 


LT 


THEN 










LD 


LOCAL, 


MEM_ 


B IT_MAP ( Rll) , 


R12 




RET 










FI 












INC 


R10 


, #1 








CP 


R10 , 


#16 








IF 


EQ 


THEN 










LD 


LOCAL 


MEM_ 


B IT_MAP (Rll) , 


R12 



R12 
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LD R10, #ZERO 
EXIT 
FI 
OD 

INC Rll, #1 
OD 

END FREE_LOCAL BIT_MAP 



FREE_GLOBAL_BIT_MAP PROCEDURE 

! PASSED PARAMETERS 
! R0 = BASE ADDR 

! R1 = 3LKS 

! LOCAL VARIABLES 
! R10 = COUNTER FOR 3IT RESET 

! Rll = BIT MAP INDEX 

! R12 = BIT MAP WORD 



ENTRY 
CLR RIG 
LD Rll, R0 

SUB Rll, #GLOBAL MEM_3ASE 
DIV BRIG, #BLK SIZE*1 6 
DO 

LD R12 , GLOBAL_MEM_B IT_MAP ( Rll ) 
DO 

RES R12, R10 



DEC 


R1 


, #1 


CP 


Rl, 


#ZERO 


IF 


LT 


THEN 




LD 


GLOBAL MEM BIT MAP(Rll) 




RET 





FI 

INC R10 , #1 
CP R10, #16 
IF EQ THEN 

LD GLOBAL MEM BIT MAP(Rll), R12 
LD R10 , #ZERO 
EXIT 
FI 
OD 

INC Rll, #1 
OD 

END FREE_GLOBAL BIT MAP 
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ALLOC_GLOBAL_M EMORY PROCEDURE 

J si:##**# ####*##:£# J 

! PASSED PARAMETER ! 

! RO = BLKS OF MEMORY ! 

! RETURNED PARAMETERS ! 

! R0 = SUCCESS_CODE ! 

! R1 = BASE_ADDR ! 

! LOCAL VARIABLES ! 

! R0 = BLKS ! 

1 R10 = BIT MAP INDEX ! 

! Rll = COUNTER FOR BIT ! 

! P.12 = BIT_MAP WORD ! 

! R13 = WORKING REGISTER ! 



LOCAL BLKS WORD 

IS.COMPACTED BYTE 
FILLER3 BYTE 

ENTRY 

LD BLKS, R0 

LDB IS_COMPACTED , #FALSE 
LD R10 , #ZERO 
DO 

CP R10 , # ( MAX_POSS_G_ BLKS/16) 

IF EQ THEN 

CPB IS COMPACTED, #FALSE 
IF EQ "THEN 

CALL COMPACT_G 
LD R10 , #ZERO 
LDB IS _COMPACTED , #TRUE 

ELSE 

LD R0, #GLOBAL_MEM_FULL 
RET 
FI 



FI 

LD Rll, #ZERO 

LD R12, GLOBAL_MEM_BIT MAP(R10) 
DO 

BIT R12, Rll 
IF Z THEN 

DEC R0 , #1 

ELSE 

LD R0 , BLKS 
FI 

CP R0, #ZERO 
IF EQ THEN 
LD Rl, R10 
MULT RR0 , #16 
ADD Rl, Rll 
SUB Rl, BLKS 
MULT RR0 , #BLK SIZE 
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ADD R1 , #GLOBAL MEM_ BASE 
LD R0, #VALID 
LD R13, BLKS 
DO 

LD R12, GLOBAL MEM_ BIT MAP(R10) 

DO 

SET R12, Rll 
DEC R13, #1 
DEC Rll, #1 
CP P.13 , #ZERO 
IF EQ TEEN 

LD GLOBAL MEM_BIT_MAP (R10 ) , 
RET 
FI 

CP Rll, #ZERO 
IF EQ THEN 

LD GLOBAL_MEM BIT_MAP(R10) 
LD Rll, #15 
DEC R10 , #1 
EXIT 
FI 
OD 
OD 
FI 

INC Rll, #1 
CP Rll, #16 
IF EQ THEN 

LD Rll, #ZERO 
EXIT 
FI 
OD 

INC R10 , #1 
OD 

END ALLOC GLOBAL MEMORY 



RFAD_?AGE PROCEDURE 

! PASSED PARAMETERS ! 

! R0 = BLK NO ! 

! Rl = BASE ADDR ! 

! RETURNED PARAMETER ! 

! R0 = SUCCESS CODE l 

! LOCAL VARIABLES ! 

! R10 = COUNTER FOR BLOCK MOVE ! 

! Rll = SIMULATED DISK ADDRESS ! 

ENTRY 

LDL RR10, #BLK SIZE 

MULT P.R10 , R0 

ADD Rll, #DISK MEM_BASE 



R12 



R12 
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LD R10, #MAX PAGE_S I ZE 
LDIR 0R1 , 3R11 , R10 
LD R0 , #VALID 
END READ_PAGE 



WR ITE_?AGE PROCEDURE 

| # ######### 
! PASSED PARAMETERS 
! R0 = BLK_NO 

! R1 = EROM_BASE_ADDR 

! RETURNED PARAMETR 
! R0 = SUCCESS CODE 
! LOCAL VARIABLES 
! R10 = COUNTER EOR BLOCK MOVE 

! Rll = SIMULATED DISK ADDRESS 

J # * £ j)s # £ ## #:Je ifif. # £ * % ^ssje # a^s^>}is^ sjcs, 1 ! 



! 

! 

! 

t 

i 

; 

i 

i 

j 

! 



ENTRY 

LDL RR10 , #BLK SIZE 
MULT RR10 , R3 
ADD Rll, #DI SK MEM BASE 
LD R10, #M AX _ P AGE _S I ZE 
LDIR OR11 , OR1 , R10 
LD R0 , #VALID 
END WRITE PAGE 



READ_SEGMENT PROCEDURE 

! PASSED PARAMETERS ! 

! R0 = PAGE_TA3LE_L0C (BLK_# ) ! 

! R1 = MEMORI_ADDR ! 

! RETURNED PARAMETER ! 

1 R0 = SUCCESS CODE ! 

! LOCAL VARIABLES l 

! R2 = INDEX FOR PAGE_TABLE_ ARRAY ! 

! R10 = COUNT FOR BLOCK MOVE ! 

! Rll = DISK BLK_# CONV TO MEM ADDR ! 

! R13 = DISK'ADDRESS ! 

j *##***#$**£*##❖*£*****$*=**£**##*****#** J 

ENTRY 

LDL RR10, #BLK_S I ZE 

MULT RR10 , R0 

ADD Rll, #DISK MEM BASE 

LD R2, #ZERO 

DO 

LD R10 , #MAX_PAGE_SIZE 
LD R13, Rll (R2 ) 

MULT RR12 , #BLK_S IZE 
ADD R13, #DISK_MEM_BASE 
LDIR ORl, 3R13, R10 
INC R2 , #1 
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CP 


R2, 


#MAX PAGE SIZE 


IF 


EQ 


THEN 




EXIT 




FI 






LD 


R0 , 


R11(R2) 


CP 


R0 , 


#ZERO 


IF 


EQ 


TEEN 




EXI 


T 


FI 






R0, 


# VALID 



END READ SEGMENT 



WRITE_SSGMZNT PROCEDURE 



1 PASSED PARAMETERS ! 
! R0 = PAGE_TA£LE_LOC (BLK_#) ! 
! Rl = MEMORY_ADDR ! 
! RETURNED PARAMETER I 
! R0 = SUCCESS CODE ! 
! LOCAL VARIABLES ! 
! RIO = PAGE TABLE ARRAY INDEX ! 



! Rll = DISK BLK NO CONV TO MEM ADDR ! 

! R13 = DISK ADDR ! 

ENTRY 

LDL RR10 , #BLK SIZE 

MULT RR10, R0 

ADD Rll, #DISK_MEM BASE 

LD R2, #ZERO 

DO 

LD R10 , #MAX PAGE SIZE 
LD R13, R11(R2) 

MULT RR12, #BLK_S IZE 
ADD R13, #DISK MEM_BASE 
LDIR 0R13 , ORlT R10 
INC R2 , #1 

CP R2, #MAX PAGE_S IZE 
IF EQ TEEN 
EXIT 
FI 

LD R0 , Rll (R2 ) 

CP R0 , #ZERO 
IF EQ THEN 
EXIT 
FI 
OD 

LD R0 , #VALID 
END WRITE SEGMENT 
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READ DISK BIT MAP PROCEDURE 

I ####################################### J 



! RETURNED PARAMETERS ! 
! R0 = SUCCESS_CODE ! 
! LOCAL VARIABLES ! 
! R10 = DISK BIT_MAP_3UFE A DDR ! 
! Rll = COUNTER FOR BLK MOVE ! 
! R13 = BIT MAP DISK ADDR ! 



j #############s|c######################### J 



ENTRY 

LD RIO , #DISK BIT_MAP 
LD R13 , #DISK_BIT_MAP_LOC 
CLR R12 

MULT RR12, #BLK SIZE 
ADD R13, #DISK MEM BASE 
LD Rll, #(MAX P0SS'D_BLKS/16) 
LDIR OR13, 0R1O , Rll 
LD RO , #7ALID 
END READ DISK BIT_MAP 



WR ITE_DISK_BIT_MAP PROCEDURE 

j ##s|c#### ########################## ###### J 

1 RETURNED PARAMETER ! 

! R0 = SUCCESS CODE ! 

! LOCAL VARIABLES ! 

! R10 = DISK BIT_MAP BUFF ADDR ! 

! Rll = COUNTER FOR BIT MAP ! 

! R13 = BIT MAP ADDRESS ! 

J ############################### ####### s|c J 

ENTRY 

LD R10 , #DISK BIT_MAP 
LD R13, #DISK~BIT_MAP LOC 
CLR R12 

MULT RR12 , #BLK SIZE 

ADD R13, #DISK MEM_BASE 

LD Rll, #( MAX_P0SS_D_BLKS/16 ) 

LDIR OR10 , 0R13 , Rll 
LD R0, #VALID 
END WRITE DISK BIT MAP 



SEARCH_DISK_BIT_MAP PROCEDURE 

j ####################################### j 



1 PASSED PARAMETER l 
! R0 = START_SRCH_BLK_# ! 
! RETURNED PARAMETERS l 
! R0 = SUCCE3S_CODE ! 
! R1 = FREE BLK_# ! 
! LOCAL VARIABLES ! 
! R10 = BIT COUNTER ! 
1 Rll = BIT MAP INDEX ! 
! R12 = BIT MAP WORD ! 



ENTRT 
CLR R10 
LD Rll , R0 
DIV RR10 , #16 

! R10 = REM, Rll = QUOT ! 

DO 

LD R12 , DISK BIT MAP (Rll) 

DO 

BIT R12 , R10 
IE Z THEN 

SET R12, R10 

LD DISK_BIT_MAP (Rll ) , R12 
LD Rl, Rll 
MULT RR0 , #16 
ADD Rl, R10 
LD R0 , #VAL ID 
RET 
FI 

INC R10 , #1 
CP R10 , #16 
IF EO THEN 

LD R10 , #ZERO 
EXIT 
FI 
OD 

INC Rll, #1 

CP Rll, #( MAX P0SS_D_BLKS/16 ) 

IF SQ THEN 

LD R0 , #SEC_STOR_FULL 
RET 
FI 
OD 

LD R0 , #VALID 
END SEARCH DISK BIT MAP 



CLEAR_DISK_BIT_MAP PROCEDURE 

! PASSED PARAMETER ! 

! R0 = BLK_N0 TO CLEAR ! 

! LOCAL VARIABLES ! 

! R10 = BIT COUNTER ! 

! Rll = BIT MAP INDEX ! 

! R12 = BIT MAP WORD ! 

ENTRY 
CLR R10 
LD Rll, R0 
DIV RR10 , #16 
! R10 = REM, Rll = QUOT ! 
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LD R12, DISK 3IT_MAP (Rll ) 
RES R12, R10 

LD DISK_BIT_MAP(R11) , R12 
END CLEAR DISK_3IT MAP 



MEMORY MOVE PROCEDURE 



j £ ### Jfcsjcj*:# j!:###:!:## £##£#### 

! PASSED PARAMETERS 
! R0 = TO ADDR 

! Rl = FROM ADDR 

! R2 = SIZE'IN BYTES 

J ####### 



I 

i 

i 

i 

i 

! 



ENTRY 
CLR R12 
LD R13, R2 
RR R13, #1 
LD R12 , R0 
LDIRB 0R12 , 0R1 , R13 
END MEMORY MOVE 



GET_UNIQ_ID PROCEDURE 



! RETURNED PARAMETERS ! 
! R0 = SUCCESS.CODE ! 
! Rl = UNIQUE ID ! 
! NOTE: WILL BE STORED ON SEC STOR ! 



LOCAL WORK SPACE BLK ARRAY [MAX PAGE SIZE WORD] 
UN IQ ID WORD 

ENTRY 

LD R0 , #SYSTEM_DATA LOC 
LD Rl, WORK SPACE_BLK 
CALL READ_PAGE 
CP R0 , #VALID 
IF NE THEN 
RET 
FI 

LD R10 , #ZSR0 ! UNIQ_ ID INDEX ! 

LD R13, WORK_SPACE_BLK(R10 ) 

LD UNIQ_ID, R13 
INC R13, #1 

LD WORK_S?ACE_BLK(R10) , R13 
LD R0 , #SYSTEM DATA_L0C 
LD Rl, #WORK_SPACE BLK 
CALL WRITE_PAGE 
LD Rl, UNIQ_ ID 
END GET UNI Q_ID 
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MAIN_LINE PROCEDURE 
ENTRY 

CALL ALLOC_LOCAL_ MEMORY 
CALL HBUG 
END MAIN_L INE 
END M MGR 2 



APPENDIX C - SWAP IN PLZ/ASM CODE 



MEM_MGR MODULE 
I * * * * VERS. 



CONSTANT 

FALSE 

TRUE 

AVAILABLE 

ACTIVE 

ZERO 

NULL 

NULL_PAGE 

HBUG 

MONITOR 



.0 « * * j 



= 0 
= 1 

= 0 ! AST 

= 1 ! AST 

= 0 

= %0000 
- 0 

= %A900 
= %059A 



ENTRY AVA ILABLE ! 
ENTRY ACTIVE ! 



! SUCCESS CODES ! 
INVALID := 0 

VALID := 1 

FOUND := 2 

NOT FOUND := 3 

SWAPPED.IN := 4 

SVAPPED_OUT := 5 

SEG ACTIVATED := 6 1 
SSG DEACTIVATED := 7 
SEG_ CREATED := 8 

SEG DELETED := 9 

LEAF SEG EXISTS := 10 
NO_LEAF_EXISTS := 11 
G_AST_FULL := 12 

L AST_FULL := 13 

IN_LOCAL MEMORY := 14 
NOT_IN LOCAL_MEM := 15 
LOCAL.MEMORY FULL:= 16 
GLOBAL MEM_FULL := 17 
VIRTUAL_CORE FULL:= 18 
DUPLICATE_ENTRY := 19 
NO_CHILD TO_DEL := 20 
SEC_ STOR FULL := 21 
DISK ERROR := 22 



ALIAS DOES NOT EXIST := 23 



! ATTRIBUTE MASKS 
READ_MASK 
WRITE MASK 



:= %( 2 ) 11 1111 10 
:= % ( 2) 00000001 
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CHANGED_MASK 
IN.MEMORY MASK 
CLEARED 

! AUTHORIZED ACCESS 
READ 
WRITE 
EXECUTE 



% ( 2)01000000 
%( 2)03030100 

0 ! CLEAR ATTR ! 

0 

1 

%( 2)00001300 



! G_AST FLAG BITS FIELD MASKS ! 

WRITABLE MASK := 2(2)00000010 

WRITTEN_MASK := 2(2)00000100 



! DESIGN PARAMETERS ! 
BLK SIZE 

NO_OF_ PROCESSORS 
M AX_DBR_NO 
G AST LIMIT 
lIast LIMIT 
MAX ENTRY NO 
NO_SEG_DESC_REG 
FST POSS FREE BLK 



= 126 
= 1 

= 4 ! EVEN NO. OF D3R_#'S ! 

= 16 1 MAX ENTRIES IN G_AST I 
= 16 ! MAX ENTRIES IN L_AST ! 
= 21 ! SIZE OF ALIAS TABLE ! 

=8 ! NO. OF SEGMENT/PROCESS ! 
= 1 



TYPE 

ADDRESS WORD 

ALI AS_HEADER RECORD [ 

SEG_PAGE_TABLE_LOC WORD 
PAR_ALIAS_ TABLE LOC WORD ] 



SEG DESC REG 



RECORD [ 

BASE ADDR ADDRESS 
LIMIT BYTE 

ATTRIBUTE BYTE ] 



ALIAS 



RECORD [ 
UNIQUE ID 
CLASS 
SIZE 

PAGE. TABLE 
ALIAS TABL 



WORD 
WORD 
WORD 
LOC WORD 
LOC WORD ] 



MMU 



RECORD [ 

SDR ARRAY 

BLKS USED 
MAX BLKS 



[NO SEG DESC REG 
SEG_DESC_REGl 
WORD 
WORD] 



G AST REC 



RECORD [ 
UNIQUE IDl 
GLOBAL_ADDR 
! ONLY ONE PROCESSOR I 



WORD 

ADDRESS 
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PROCESSORS L_ASTE_ NO WORD 
! WRITTEN BIT AND WRITABLE BIT ! 
FLAG_BITS WORD 

G_ASTE_NO PAR WORD 
NO_ACTI VE_IN_MEMORT WORD 
NO ACTIVE DEPENDENTS WORD 
PAGE TABLE LOCI WORD 
SIZE1 ' WORD 
ALIAS TA3LE_L0C1 WORD 
SEQUENCER WORD 

INSTANCE1 WORD 

INSTANCE2 WORD ] 

L_AST_REC RECORD [ 

MEMORY ADDR ADDRESS 

SEGMENT_ NO ACCESS_AUTH ARRAY 
[MAI_DBR_NO BYTE] ] 
HANDLE RECORD [ 

UNIQUE_ID2 WORD 
H_ INDEX WORD ] 



GLOBAL 

! $S ECT ION G_ DATA ! 

G AST ARRAY [G AST_LIMIT G_AST_REC] 

G_AST_LOCK BYTE 

DISK_BIT_MAP_ LOCK BYTE 

! $ SECTION L_DATA ! 

MMU IMAGE ARRAY [MAX DBR NO MMU] 

L_AST ARRAT [L_AST_LI MI T L_AST REC] 

ALIAS TABLE RECORD [ HEADER ALIAS.HEADER 

ALIAS ENTRY ARRAY 
[MAX_ENTRY_NO ALIAS] ] 
DISK_BIT MAP BUFF ARRAY [6 BYTE] 

PAGE TABLE_BUFFER ARRAY [BLK_SIZE BYTE] 

EXTERNAL 



ALLOC_LOCAL MEMORY PROCEDURE 
ENTRY 

END ALLOC LOCAL MEMORY 



READ_SEGMENT PROCEDURE 
ENTRY 

END READ_SEGMENT 
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FRES_LOCAL_BIT_MAP PROCEDURE 
ENTRY 

END FREE LOCAL BIT MAP 



ALLOC GLOBAL_MEMORY PROCEDURE 
ENTRY 

END ALLOC GLOBAL MEMORY 



MOVE_TO GLOBAL PROCEDURE 
ENTRY 

END MOVE_TO_GLOBAL 

S IGNAL_OTHER_MEMORY_ MANAGERS PROCEDURE 
ENTRY 

END S IGNAL_OTHER_MEMORY_MANAGERS 
INTERNAL 

UPDATE_MMU_ IMAGE PROCEDURE 



! PASSED PARAMETERS ! 
1 R0 = DBR # ! 
! R1 = SEGMENT # ! 
! R2 = ADDR " ! 
! R3 = ACCESS ! 
! R4 = LIMIT ! 
! LOCAL VARIABLES ! 
! R10 = WORKING REGISTER ! 
! R13 = WORKING REGISTER ! 



'entry 

LD R10, #MMU IMAGE 
LD R13, #S IZEOF MMU 
MULT RR12, R0 
ADD R10, R13 

LD R13 , #S IZEOF SSG_DESC_REG 
MULT RR12, R1 



ADD 


P.10, 


R13 


LD 


OR10 , 


R2 


INC 


R10 , 


#2 


LDB 


OR10 


, RL4 


INC 


R10 , 


#1 


LDB 


RL4, 


OR10 


CPB 


RL3, 


#EXECUTE 



IF EQ THEN 

ANDB RL4 , #%(2)11110111 

ELSE 

ANDB RL4 , #%(2)11111110 
FI 
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ORB RL4, RL3 
LDB 0R10 , RL4 
R ET 

END UPDATE_MMU_IMAGE 



UPDATE_L_ AST_ACCESS PROCEDURE 

| ###################################### { 
! PASSED PARAMETERS ! 

! R0 = INDEX ! 

! Rl = ACCESS AUTE ! 

! R2 = D3R # ! 

! LOCAL VARIABLES ! 

! R5 = WORKING REGISTER ! 

! R7 = WORKING REGISTER ! 

| ###################################### J 

ENTRY 

LD R5 1 #L_ AST 

LD R7 , #SIZE0F L_AST_REC 

MULT RR6 , R0 

ADD R7, #2 

ADD R7, R2 

ADD R5 , R7 

LDB RL3, 0R5 

CP3 RL1, #WRI TE 

IF EQ THEN 

ORB RL3 , #%( 2 ) 10000000 
LDB 0R5, RL3 

ELSE 

ANDB RL3, #%(2 )01111111 
LDB 0R5 , RL3 
FI 
RET 

END UPDATE L_AST_ACCESS 



CHECK LOCAL_MEMCRY PROCEDURE 

| a* sjssje# #s)c £ #s{c>jc a*## *;JtaJc&j>ssi:a>:£#5£aj5*#;fc f 



PASSED PARAMETERS ! 

R0 = INDEX i 

RETURNED PARAMETER ! 

R0 = TEST ! 

LOCAL VARIABLES ! 

R2 = I ! 

R3 = SEG_ NO ! 

RH3 = ATTRIBUTES ! 



! R10 = ADDR OF MMU_ IMAGE . SDR [SEG#] ! 
! Rll = ADDR OF L_AST [R3] .SEG/ACC [I] ! 
! R12 , 13 = WORKING REGISTERS ! 

ENTRY 



156 



LD 

DO 



OD 



R2, #ZERO 

CP R2, #MAX DBR NO 
IP EQ THEN 

LD R0 , #NOT_I N LOCAL MEM 
RET 
FI 

LD Rll, #L_AST 
LD R13, #SIZEOF L_AST_REC 
MULT RR12, R0 
ADD Rll, R13 

ADD Rll, #2 1 SEGMENT NO OFFSET ! 

ADD Rll, R2 
LD3 RL3 , OR 11 
CLRB RH3 

ANDB RL3 , %(2)01111111 
CPB RL3 , #ZERO 
IF NE TEEN 



LD R10 , #MMU IMAGE 
LD R 13 , #S I ZEOF MMU 
MULT RR12 , R2 
ADD R10 , R13 
ADD R10 , R3 

ADD R10 , #3 ! ATTRIBUTES OFFSET ! 

LDB RE1 , OR10 

ANDB RH1, #IN_MEMORY MASK 

CPB RE1 , #ZERO 

IF NS TEEN 

LD R0 , #IN_LOCAL MEMORY 
RET 
FI 
FI 

INC R2 , #1 



END CHECK LOCAL MEMORY 



CHECK_MAX_VIRTUAL_ CORE PROCEDURE 

J £#### 3$C ###### £ ####### J 

! PASSED PARAMETERS ! 

! R0 = DBR # ! 

! R1 = BLKS ! 

! RETURNED PARAMETER ! 

! R0 = SUCCESS CODE ! 

! LOCAL VARIABLES ! 

! R10.R12 = WORKING REGISTERS ! 

ENTRY 

LD R10 , #MMU IMAGE 
LD R13 , #S IZEOF MMU 
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MULT RR12, R0 
ADD R10, R13 

LD R13, #S IZEOF SEG.DESC REG 

MULT RR12, #NC SEG_DESC_REG 

ADD R10 , R13 

LD R12, OR10 

ADD R12, R1 

INC R10 , #2 

CP R12, OR 10 

IF GT THEN 

SUB R12, R1 

LD R0, #VIRTUAL_CORE_FULL 

ELSE 

LD R0, #VALID 
FI 

DEC R10, #2 
LD OR 1 0 , R12 
RET 

END CBECK_MAX_VIRTUAL_CORE 
S WAP_ IN PROCEDURE 

! PASSED PARAMETERS ! 

! R0 = INDEX ! 

! R1 = D3R_# ! 

! R2 = ACCESS ! 

! RETURNED PARAMETER ! 

! R0 = SUCCESS CODE ! 

J £ a*#### j 

LOCAL INDEX WORD 



ENTRY 

LD INDEX, R0 

LD DBR NO, R1 

LD ACCESS, R2 

LD R5 , #G_ AST 

LD R13, #SIZEOF G_AST_REC 

MULT RR12, R0 

ADD R5 , R13 

LD G AST BASE, R5 

ADD R5 , #16 ! SIZE OFFSET ! 

CLR R6 
LD R7, 0R5 
DIV RR6, #3LK_S IZE 
LD R6 , R7 

DEC R5, #12 ! L AST INDEX OFFSET ! 

LD R7 , 0R5 
LD R0 , Rl 
LD Rl, R6 



DBR NO 
ACCESS 
G AST BASE 



WORD 

WORD 

ADDRESS 
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CALL CHECK MAX VIRTUAL CORE 



CP 


R0, #VIRTUAL CORE FULL 




IF 


EQ THEN 
RET 




FI 






INC 


R5 , #4 ! NO ACTIVE 


IN_MEMORY OFFSET ! 


INC 


0R5, #1 




LD 


R8, 0R5 




CP 


ACCESS, #WRITE 




IF 


EQ THEN 

DEC R5 , #4 ! OFFSET 

LD R4, 0R5 

OR R4 , #WRITA3LE MASK 
LD 0R5 , R4 


TO FLAG..BITS ! 


FI 






LD 


R0 , R7 




CALL CHECK LOCAL MEMORY 




AND 


R4, WRITABLE MASK 




CP 


R4, #0 




IF 


NE THEN 
CP R8 , #1 
IF GT THEN 





CP RC, #IN LOCAL_ MEMORY 
IF NE THEN 
LD R0 , R6 

CALL ALLOC_LOCAL MEMORY 
CP R0 , #LOCAL_MEMORY FULL 
IF EQ THEN 
RET 
FI 

LD R9 , R1 

INC R5, #8 ! PAGE_ TABLE _LOC OFFSET ! 

LD R0 , 0R5 
CALL READ_SEGMZNT 
CP R0 , #VALID 
IF NE THEN 
LD R0 , R9 
LD Rl, R6 

CALL FREE LOCAL BIT MAP 
RET 
FI 

LD R10 , #L_AST 

LD R13 , #S IZEOF L_AST_REC 

MULT RR12, R? 

ADD R10 , R13 IMEMORY ADDR OFFSET INTO L_AST ! 
LD OR10, R9 

ELSE 

LD R10 , #L_AST 

LD R13 , #S I ZEOF L_AST_REC 

MULT RR12, R7 

ADD R10 , R13 
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LD R9 , GR10 
FI 
FI 

ELSE 

LD R8 , R0 

LD R5 , G AST BASE 

INC R5 , #2 ! GLOBAL ADDR OFFSET ! 

LD R12, GR5 
CP R12, #NULL 
IF EQ THEN 
LD R0 , R6 

CALL ALLOC_GLOBAL MEMORY 
CP R0 , #GLOBAL MEM_ FULL 
IF EQ THEN 
RET 
FI 

LD R9 , R1 

CP R8 , #1 N_LOCAL_MEMORY 
IF EQ THEN 
LD R0 , R7 

INC R5 , #14 ! SIZE OFFSET ! 

LD R2, GR5 
CALL MOVE_TO_ GLOBAL 
CP R0, #VALID 
IF NE THEN 
RET 
FI 

ELSE 

LD R0 , R1 
LD Rl, INDEX 

CALL SIGNAL_OTHER MEM ORY_ MANAGERS 
CP R0, #VALID 
IF NE THEN 
RET 
FI 
FI 

ELSE 

LD R5 ,G_AST BASE 

ADD R5 , #2 ! GLOBAL ADDR OFFSET ! 

LD R9 , GR5 
FI 
FI 

LD R0 , DBR NO 

LD R10 , #L"AST 

LD R13, #SI ZEOF L_AST REC 

MULT RR12 , R7 

ADD R10, R13 

ADD R10, R0 

INC R10 , #2 

LDB ELI, OR 10 

LD R2, R9 
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LD R3, ACCESS 
LD R4, R 6 

CALL UPDATE MMU IMAGE 
LD R0 , R7 
LD Rl, ACCESS 
LD R2, DBR NO 
CALL UPDATE_L AST ACCESS 
LD R0 , #SVAPPED IN 
END SWAP_IN 

MAIN_LINE PROCEDURE 
ENTRY 

CALL SWAP_IN 
CALL H3UG 
END MA IN_L I NE 
END MEM MGR 
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